Username/Password auth: improve auth flow

[mikeleigh]

Just migrated from Rundeck 2.6.11 to 2.8.2-1 on a CentOS 6.5 Server using the standard yum method and am noticing some errors with the rundeck.log.

Using 2.6.11 (and earlier versions) the "rd-jobs load" with yaml files was working perfectly for us. We have migrated our scripts to use "rd jobs load" with the new rd tools and have noticed the following behaviour in the rundeck.log.

2017-05-22 15:06:32,112 [qtp363771819-17] ERROR grails.app.filters.rundeck.filters.AuthorizationFilters - Unauthenticated API request
2017-05-22 15:06:32,112 [qtp363771819-17] ERROR grails.app.filters.rundeck.filters.AuthorizationFilters - (unauthenticated) UNAUTHORIZED for scheduledExecution/apiJobsImportv14
2017-05-22 15:06:32,238 [qtp363771819-16] INFO grails.app.services.rundeck.services.ScheduledExecutionService - creating trigger with crontab expression: 0 01 18 ? * * *
2017-05-22 15:06:32,238 [qtp363771819-16] INFO grails.app.services.rundeck.services.ScheduledExecutionService - scheduling new job in project NAME_OF_PROJECT 5da8dbc9-d542-404e-80d9-3a20ab214b80: 343:NAME_OF_JOB
2017-05-22 15:06:32,239 [qtp363771819-16] INFO grails.app.services.rundeck.services.ScheduledExecutionService - scheduled job 5da8dbc9-d542-404e-80d9-3a20ab214b80. next run: Mon May 22 18:01:00 UTC 2017

We receive two ERROR notifications and then the job is loaded and scheduled accordingly.

The same yaml files were working on 2.6.11. The job within Rundeck works flawlessly (from the GUI) and even exports the same yaml as we are loading.

The rd.conf has been created and we have entries for the following:

• RD_URL
• RD_USER
• RD_PASSWORD

Do you need any additional information? Is this is a bug / issue, user error or soemthing we have missed entirely?

[gschueler]

@mikeleigh You can ignore that, it is not an error when you are using username/password authentication. The rd tool first makes the API request without authentication to receive an "Unauthenticated" response, before submitting the username/password for authentication.

It could be more sophisticated with detecting when/how to send authentication.

If it is really undesirable for you, you could switch to Token authentication which does not do that.

I will rename this issue to reflect that the Form auth flow should be enhanced for a nicer interaction with the server.

[mikeleigh]

@gschueler switching to token authentication removes these errors as suggested. It does however add the headache of the expiring 30 day tokens, a different issue.
I believe this should be made to behave with a much "nicer" user interaction. Especially when the users that will primarily be interacting have a much greater aversion to the word ERROR, especially after upgrading and seeing a log file with errors.
I agree with you renaming the issue and creating an enhancement from this.

[gschueler]

@mikeleigh yes. fyi the 30 day limit is the default, can be changed or removed. see http://rundeck.org/docs/administration/configuration-file-reference.html#security under rundeck.api.tokens.duration.max

[mikeleigh]

@gschueler I figured you may have an option for that but I just hadn't got around to looking for it yet. Looking forward to seeing the enhancement when it is ready. Thanks.