You are not logged in.
Pages: 1
Hi,
I'm looking for a way to script the execution of a number of reports with various parameters in order to run a sanity test of reports after deploying a new version.
I was thinking I could use curl to call the reportexport servlet, but I couldn't find a way to get curl to log in to RS.
I know there's the httpauthexport servlet that allows reports to be called from curl with a configured username and password, but I don't think it's quite what I want. It only allows a single system-wide username and password to be used for all reports, and since I'm using that feature for another purpose already, I'd be exposing more capability than I want to the holders of the httpauthexport username/password.
I suppose I'm looking for advice to log into the UI using curl, or hints toward another way to generate reports from predefined parameters.
Or, alternatively, maybe this could be made easier by enhancing httpauthexport to support multiple usernames and passwords, each with a different set of allowed reports. That seems less than elegant, though, given it would duplicate some of RS's existing privilege management functionality.
Looking forward to hearing your ideas,
Mike
Offline
Hi Mike,
using curl to login to reportserver is rather complicated, as the authenticator endpoint uses gwt-rpc, so I think extending the httpauthexport servlet is the better approach. Actually improving the whole authexport thing is something already on our agenda (the idea is to introduce api-keys and use normal reportserver permissions to control access) but I don't know when this will be available, yet.
For now I would just go with a web-accessible script, that handles the authentication and delegates to the standard ReportExportServlet. Maybe take a look at the current implementation of the HttpAuthExecuteServlet, it basically does exactly that, you just have to swap current authentication for something a little more clever.
I hope that gives you an idea where to start, let me know if there is anything I can do to help.
Cheers,
Thorsten
Offline
I just realised I skipped the part on not duplicating the existing privilege management: You can of course use the AuthenticatorService to validate credentials and log-in a user so privilege evaluation will work. I probably would't use the regular password for this but would go for something static. Maybe a group for all users that are allowed to use this and a shared secret instead of a password, so you won't be able to use this information for interactive login.
Cheers,
Thorsten
Offline
Pages: 1