-
Notifications
You must be signed in to change notification settings - Fork 172
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
Fix crumb issue #195
Fix crumb issue #195
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. @martinda feel free to merge when ready.
I have some ideas on how to test this. I would need to add the API for getting a token, which might be useful in other circumstances. The anonymous mode should be testable as well since the live container allows anonymous read access, but I am not there yet. |
b8cdc25
to
2af8767
Compare
I added mockTests, but I still don't have live tests. I prefer to have live tests before merging. |
Just to say that I found how to write the live integration test. Anonymous access is only testable when the Authorization strategy is "anyone can do anything". The live tests still pass when the test server in docker is configured as such. But the strange part is that the crumb for the anonymous user is only needed when POSTing. One might question: why bother with anonymous? The answer is that it's very useful to pre-configure Jenkins using anonymous access without adding an "artificial" account that does not exist on the production server where the user database resides in LDAP or other external system. Anyway, just wanted to say the solution is found, now it's about implementing it. |
As part of testing the crumb feature, I needed to dynamically switch from |
b5b7647
to
8ad6593
Compare
@cdancy This is ready for a review. Lots of major changes internally. |
Background
This fixes the crumb issue #169
The Jenkins documentation states that:
username:password
must request a crumb.Furthermore, the Cloudbees documentation states that:
Anonymous access is rare but possible. It happens when users start Jenkins without the wizard and without configuring users.
Solution description
The main difficulty faced when addressing this issue is that the current jenkins-rest implementation does not clearly distinguishes between
username:password
andusername:apiToken
. The only way I could solve it was by introducing a the newJenkinsClient.builder().apiToken("username:apiToken")
API.Note that jenkins-rest has a Bearer Token implementation, but Jenkins supports no such thing. This PR removes the Bearer Token implementation in favor of what Jenkins supports: Anonymous Authentication and Basic Authentication. Basic Authentication is used for both
username:password
andusername:apiToken
.Testing
There are three cases to test:
I have tested all cases on a local live server, however providing unit and integration tests requires more work.
I am not sure how to provide tests for 1. and 3. The docker container used for Live tests is preconfigured using
username:password
which means we're currently only testing for case 2.It is possible to obtain an API Token using the REST API, so conceivably a test can be written for case 3. I just haven't gotten to that part yet.