|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
Ok, so I pulled the latest code and did some testing and this is what I've found.
It is related to the change in User.java -https://github.com/jenkinsci/jenkins/blob/0e339d7a454df119995b896eea14f09a099f99b5/core/src/main/java/hudson/model/User.java#L264
That line re-throws the UsernameNotFoundException.
Scenario #1
Security is not enabled. User passes a key to jenkins-cli -i <key-file> => returns an EOFException.
Commented out throw UsernameNotFoundException in User.java.
Test #1 -> pass key for user defined when security was enabled => Jenkins reports the user as authenticated
Test #2 -> pass random private key => Jenkins reports Authentication failed.
Scenario #2
AD security is enabled. User passes a key for a user defined in Jenkin's user database => returns an EOFException.
Change the AD plugin to throw a UserMayOrMayNotExistException.
Test #1 -> pass key for user defined in AD => Jenkins reports the user as authenticated.
Test #2 -> pass key for user defined in Jenkins Database => Jenkins reports the user as authenticated.
Test #3 -> pass random private key => Jenkins reports auth failed.
I think the issue here is that for Scenario #1, the SecurityRealm.None implementation throws a UsernameNotFoundException for loadByUsername(id). This is no handled differently. I suspect the answer is that it should throw s UserMayOrMayNotExistException instead.
This would be the same problem with the AD plugin...it throws a UsernameNotFoundException if the user doesn't exist in AD, that exception percolates up and causes the EOF. Instead, the plugin should throw UserMayOrMayNotExistException, so Jenkins falls back.