[JENKINS-57154] Fix configureSecurity HTTP 403 err#115
Conversation
|
@Wadeck @agentgonzo I've tested this locally in a Jenkins instance after replicating the bug JENKINS-57154 and verified the fix is good. I'm not sure how to test this automatically as code, though. |
| HttpPost httpost = new HttpPost(githubWebUri | ||
| + "/login/oauth/access_token?" + "client_id=" + clientID + "&" | ||
| + "client_secret=" + clientSecret + "&" + "code=" + code); | ||
| + "client_secret=" + clientSecret.getPlainText() + "&" + "code=" + code); |
There was a problem hiding this comment.
Unrelated to JENKINS-57154. This is to fix the following warning.
WARNING: Use of toString() on hudson.util.Secret from java.lang.String.valueOf(String.java:2994). Prefer getPlainText() or getEncryptedValue() depending your needs. see https://jenkins.io/redirect/hudson.util.Secret/
|
I'll leave this open for a day before merging. We could always write tests later after the fact as well. |
a27d922 to
82ca634
Compare
|
I still get When attempting to save the security page so this isn't fixed... |
|
Every time I visit http://localhost:8080/configureSecurity/ then http://localhost:8080/crumbIssuer/api/json?pretty=true changes... this is different from what I recall |
Replicates the same behavior as logging out and logging back in... I think my the security realm searching the matrix auth is to blame because it basically seems like a complete re-auth. |
|
Well this isn't a complete fix because the CSRF token keeps getting regenerated when visiting the security page. |
Wadeck
left a comment
There was a problem hiding this comment.
Not tested manually but nothing seems wrong :)
82ca634 to
279dcf9
Compare
| } catch (IOException e) { | ||
| throw new UserMayOrMayNotExistException("Could not connect to GitHub API server, target URL = " + getGithubApiUri(), e); | ||
| } | ||
| SecurityContextHolder.getContext().setAuthentication(token); |
There was a problem hiding this comment.
SecurityContextHolder.getContext().setAuthentication(token); is what kept throwing the CSRF errors because global security page would generate a new CSRF token for the authenticated user every time the page was visited. So the form on the page would have an out-of-date CSRF token since doCheck would generate a new one for the logged in user (admin).
If an admin visits the `configureSecurity` page in Jenkins, then every user queried will attempt to be impersonated as part of determining if they're a user. However, it's possible for some users to revoke the OAuth app or no longer have access so impersonation is not possible due to an invalid token. The `GithubAuthenticationToken` class did not properly surface an error when a token authentication was not valid. See also: - [JENKINS-57154][JENKINS-57154] Regression in github-oauth-plugin 0.32 breaks /configureSecurity page [JENKINS-57154]: https://issues.jenkins-ci.org/browse/JENKINS-57154
279dcf9 to
65f0d3d
Compare
Impersonation script console code (click to expand)import jenkins.model.Jenkins
import org.acegisecurity.context.SecurityContextHolder
Jenkins.instance.ACL.as(User.get('samrocketman')).with { ctx ->
try {
// access Jenkins job only user has access
println "Can delete? ${(Jenkins.instance.getItemByFullName('test')?.hasPermission(Item.DELETE))? "Yes" : "No"}."
println "Granted Authorities"
println " ${SecurityContextHolder.getContext().getAuthentication().authorities.join('\n ')}"
} finally {
ctx.close()
}
} |
If an admin visits the
configureSecuritypage in Jenkins, then every user queried will attempt to be impersonated as part of determining if they're a user. However, it's possible for some users to revoke the OAuth app or no longer have access so impersonation is not possible due to an invalid token.The
GithubAuthenticationTokenclass did not properly surface an error when a token authentication was not valid.See also: