New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Username/Password auth: improve auth flow #102

Closed
mikeleigh opened this Issue May 22, 2017 · 4 comments

Comments

Projects
None yet
2 participants
@mikeleigh

mikeleigh commented May 22, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gschueler

gschueler May 22, 2017

Member

@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.

Member

gschueler commented May 22, 2017

@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.

@gschueler gschueler changed the title from Error / Unauthorized for scheduledExecution/apiJobsImportv14 to Username/Password auth: improve auth flow May 22, 2017

@mikeleigh

This comment has been minimized.

Show comment
Hide comment
@mikeleigh

mikeleigh May 22, 2017

@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.

mikeleigh commented May 22, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@gschueler

gschueler May 22, 2017

Member

@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

Member

gschueler commented May 22, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@mikeleigh

mikeleigh May 22, 2017

@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.

mikeleigh commented May 22, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment