[JIRA] (JENKINS-56997) this.me NullPointerException in GithubAuthenticationToken.java oauth

8 views
Skip to first unread message

mail+jenkins@nh2.me (JIRA)

unread,
Apr 12, 2019, 7:13:01 PM4/12/19
to jenkinsc...@googlegroups.com
Niklas Hambuechen updated an issue
 
Jenkins / Bug JENKINS-56997
this.me NullPointerException in GithubAuthenticationToken.java oauth
Change By: Niklas Hambuechen
Summary: this.me NullPointerException in GithubAuthenticationToken.java oauth
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

mail+jenkins@nh2.me (JIRA)

unread,
Apr 12, 2019, 8:31:03 PM4/12/19
to jenkinsc...@googlegroups.com
Niklas Hambuechen commented on Bug JENKINS-56997
 
Re: this.me NullPointerException in GithubAuthenticationToken.java oauth

I've worked around it by now by following https://github.com/jenkinsci/github-oauth-plugin/tree/6165ab2acc4e9e39cbc67d231187e859f3524ff3#troubleshooting-installation, resetting the relevant sections in Jenkins's config.xml to

<securityRealm class="hudson.security.HudsonPrivateSecurityRealm"></securityRealm>

and thus re-initialising the plugin (note this sets Jenkins back into a state where any user can register by themselves, so better disconnect it from the Internet before so that nobody can exploit this).

After re-entering my unchanged Github OAuth client ID and secrent, and confirming the Github question whether to approve it, it's working again (and now also behind HTTP basic auth which I added just after).

It would still be good to figure out what caused this NullPointerException in case other people have the same problem.

mail+jenkins@nh2.me (JIRA)

unread,
Apr 12, 2019, 8:32:02 PM4/12/19
to jenkinsc...@googlegroups.com

Here's one thing I noticed:

Before, in the broken setup, config.xml contained

code
<oauthScopes>read:org,user:email</oauthScopes>
code

codecode

mail+jenkins@nh2.me (JIRA)

unread,
Apr 12, 2019, 8:33:02 PM4/12/19
to jenkinsc...@googlegroups.com
Niklas Hambuechen edited a comment on Bug JENKINS-56997
Here's one thing I noticed:

Before, in the broken setup, {{config.xml}} contained

{ { code} }
    <oauthScopes>read:org,user:email</oauthScopes>
{ { code} }


Now in the fixed setup, it contains

{ { code} }
    <oauthScopes>read:org,user:email,repo</oauthScopes>
{ { code} }

Beyond that, nothing but the saved client {{clientSecret}} (apparently encoded in some form as it's longer than what's shown in Github) changed.

mail+jenkins@nh2.me (JIRA)

unread,
Apr 12, 2019, 8:33:02 PM4/12/19
to jenkinsc...@googlegroups.com

mail+jenkins@nh2.me (JIRA)

unread,
Apr 12, 2019, 8:43:03 PM4/12/19
to jenkinsc...@googlegroups.com

And indeed, deleting the ,repo part and restarting Jenkins brings back the NullPointerException, and adding it back afterwards does not help and it persists, and I have to wipe the credentials again to fix it.

That feels like a bug.

I suspec that the change that introduced this into my Jenkins was this (included first time in github-oauth-0.31):

https://github.com/jenkinsci/github-oauth-plugin/commit/7a4539f8c6f245b83c78b61acb3c94bfe43652b5#diff-fab2dd7bd575663bdf8f8879e047ba54R109

mail+jenkins@nh2.me (JIRA)

unread,
Apr 12, 2019, 9:10:02 PM4/12/19
to jenkinsc...@googlegroups.com

For others also trying to use HTTP Basic Auth in front of Jenkins, an important trick is that after doing the HudsonPrivateSecurityRealm reset, one cannot login at all if the basic auth is enabled in nginx; that has to be turned off first.

Otherwise it keeps asking for a HTTP basic auth password in the browser and accepts none, not even the one it had accepted before.

mail+jenkins@nh2.me (JIRA)

unread,
Apr 12, 2019, 9:36:02 PM4/12/19
to jenkinsc...@googlegroups.com

OK, I compiled the plugin from source and added some logs.

This assertion

https://github.com/jenkinsci/github-oauth-plugin/blob/6165ab2acc4e9e39cbc67d231187e859f3524ff3/src/main/java/org/jenkinsci/plugins/GithubAuthenticationToken.java#L201

has no effect, it is just continued past. This is most likely because assertions are off by default on the JVM unless you enable them with java -ea (which is short for -enableassertions).

Should this really be an assertion, or should this be a proper check with if and throwing an exception?

mail+jenkins@nh2.me (JIRA)

unread,
Apr 12, 2019, 9:49:02 PM4/12/19
to jenkinsc...@googlegroups.com

OK, with more logging I found a couple more things that are wrong here.

This code is triggered:

https://github.com/jenkinsci/github-oauth-plugin/blob/6165ab2acc4e9e39cbc67d231187e859f3524ff3/src/main/java/org/jenkinsci/plugins/GithubAuthenticationToken.java#L494

        } catch (IOException e) {
            LOGGER.log(Level.FINEST, e.getMessage(), e);
            me = UNKNOWN_TOKEN;
usersByTokenCache.put(token, UNKNOWN_TOKEN);

but because it uses FINEST logging, the error message never appears anywhere. The exeception e is:

org.kohsuke.github.GHFileNotFoundException: {"message":"Bad credentials","documentation_url":"https://developer.github.com/v3"}

Why does the code catch the much more general IOException instead of GHFileNotFoundException or some general Github-specific error?

The code then also does me = UNKNOWN_TOKEN; where UNKNOWN_TOKEN = new GithubMyself(null);, so that's where the null comes from. In the face of this, the use of assert mentioned above looks quite certainly wrong, as Github complaining about bad credentials is a normal code path that can be taken, and should thus be always checked.

It seems right now there's no code path that clearly tells the user what Github's error message is ("Bad credentials"), which is bad.

mail+jenkins@nh2.me (JIRA)

unread,
Apr 12, 2019, 10:38:02 PM4/12/19
to jenkinsc...@googlegroups.com

OK, I think I found a key underlying problem for why the NullPointerException comes back to me repeatedly.

If I try to fix the problem by switching back to HudsonPrivateSecurityRealm, logging in as some local user, say admin, Jenkins prompts me with HTTP Basic Auth, into which I have to put my user admin. If I then then enable Github login, then I'll also get the NullPointerException, because in this code

https://github.com/jenkinsci/github-oauth-plugin/blob/6165ab2acc4e9e39cbc67d231187e859f3524ff3/src/main/java/org/jenkinsci/plugins/GithubSecurityRealm.java#L531

the authentication printed shows as

org.acegisecurity.providers.UsernamePasswordAuthenticationToken@8cffbcaa: Username: admin; Password: [PROTECTED]

Se how there's admin in here. That's because I haven't had a chance to log out of HTTP Basic Auth. I can see the Authorization: Basic ... header being set in the dev tools, and in fact, browsers like Firefox have no method to display visually that it's still being sent, or even to clear HTTP basic auth for just a single site (see https://bugzilla.mozilla.org/show_bug.cgi?id=540516#c2), but Firefox's Clear History... -> [x] Active Logins does the trick (wiping all sites' Basic Auth). And Jenkins / the Github plugin seems to pick up this Basic Auth header, and thus try to authenticate me to Github as admin (which can't work) instead of doing a normal Github OAuth.

Then when that happens, the above-found problems with lack of error reporting that the auth failed kick in, and the NullPointerException is thrown.

mail+jenkins@nh2.me (JIRA)

unread,
Apr 12, 2019, 10:46:02 PM4/12/19
to jenkinsc...@googlegroups.com

Finally, let's get back to Basic Auth in the nginx reverse proxy in front of Jenkins.

When I have cleared the Basic Auth as described and everything is working, and I then enable Basic Auth in nginx, I get a password prompt (into which I put my nginx-configured credentials, let's say username niklas), and everything continues working fine (I'm still logged in in Jenkins and can browse around). But as soon as I click Logout in Jenkins, everything breaks, and I cannot get logged back in with Github.

That is because we now have the same problem as before: The plugin picks up nginx's Basic Auth and uses that user to Github:

org.acegisecurity.providers.UsernamePasswordAuthenticationToken@dc12364c: Username: niklas; Password: [PROTECTED]

Which is wrong, because it should use the normal OAuth and ignore nginx's Basic Auth.

That means right now, you can't run Jenkins behind nginx with Basic Auth while also using the github-oauth-plugin.

So it seems there should be a way to disable the second branch in

                if (authentication instanceof GithubAuthenticationToken)
                    return authentication;
                if (authentication instanceof UsernamePasswordAuthenticationToken)
                    try {

being taken, and forcing Github auth no matter the HTTP auth.

mail+jenkins@nh2.me (JIRA)

unread,
Apr 12, 2019, 11:14:02 PM4/12/19
to jenkinsc...@googlegroups.com
Niklas Hambuechen edited a comment on Bug JENKINS-56997
OK, I think I found a key underlying problem for why the NullPointerException comes back to me repeatedly , and also why it only appeared the first time after I shortly turned on Basic Auth in nginx .

If I try to fix the problem by switching back to {{HudsonPrivateSecurityRealm}}, logging in as some local user, say {{admin}}, Jenkins prompts me with HTTP Basic Auth, into which I have to put my user {{admin}}. If I then then enable Github login, then I'll also get the {{NullPointerException}}, because in this code
{code}

org.acegisecurity.providers.UsernamePasswordAuthenticationToken@8cffbcaa: Username: admin; Password: [PROTECTED]
{code}


Se how there's {{admin}} in here. That's because I haven't had a chance to log out of HTTP Basic Auth. I can see the {{Authorization: Basic ...}} header being set in the dev tools, and in fact, browsers like Firefox have no method to display visually that it's still being sent, or even to clear HTTP basic auth for just a single site (see https://bugzilla.mozilla.org/show_bug.cgi?id=540516#c2), but Firefox's {{Clear History... -> [x] Active Logins}} does the trick (wiping all sites' Basic Auth). And Jenkins / the Github plugin seems to pick up this Basic Auth header, and thus try to authenticate me to Github as {{admin}} (which can't work) instead of doing a normal Github OAuth.

Then when that happens, the above-found problems with lack of error reporting that the auth failed kick in, and the NullPointerException is thrown.

mail+jenkins@nh2.me (JIRA)

unread,
Apr 12, 2019, 11:14:02 PM4/12/19
to jenkinsc...@googlegroups.com

I found a workaround for the above to use with nginx:

proxy_set_header Authorization "";

This makes sure nginx does not pass through any HTTP Basic Auth (or other authorization) header to Jenkins.

So the remaining tasks for this ticket should probably be:

  • Better error messages (don't swallow Bad credentials from Github, don't use assert here)
  • Make it somehow possible to disable the plugin picking up Basic Auth and passing it to Github, especially after just switching from another Jenkins auth method to Github auth

sascha.vujevic@ergodirekt.de (JIRA)

unread,
Apr 29, 2019, 9:05:03 AM4/29/19
to jenkinsc...@googlegroups.com

Hello developers,

is there any approach on this issue ?

We are using github-oauth-plugin within our Jenkins (based in rhel 7) in AWS and have still this problem with version 0.32.

Version 0.29 works but has security issues.

Thanks for your help.

Best regards,

   Sascha Vujevic

sascha.vujevic@ergodirekt.de (JIRA)

unread,
Apr 29, 2019, 9:29:02 AM4/29/19
to jenkinsc...@googlegroups.com

Hello developers,

seems to work. I think it was part of caching and wrong configuration of

<oauthScopes>read:org,user:email,repo</oauthScopes>

and wrong githubApiUri.

Thanks.

 

mimeczek@gmail.com (JIRA)

unread,
Jul 1, 2019, 9:58:04 AM7/1/19
to jenkinsc...@googlegroups.com

I have also encountered this problem while upgrading jobs and Jenkins from an old version for core and plugin to latest ones (0.32). The same error and issues appeared for old jobs which should be migrated. But when I create a new job with same settings for GitHub multibranch it worked properly. When tried to copy old, broken to a new one (create new base on old one) error persist. When I downgraded plugin version to 0.31 old jobs which were migrated also started to work, so for my case, problems seems to be in the latest version of plugin (0.32) and old jobs. I also have basic auth in front of Jenkins but it's optional when accessing instance from trusted IPs and I've found that header Authorization was missing in requests, but error persisted. So I think it's not only related with nginx reverse proxy behind Jenkins.

Kind regards,
Marcin

mimeczek@gmail.com (JIRA)

unread,
Jul 1, 2019, 10:00:02 AM7/1/19
to jenkinsc...@googlegroups.com
Marcin Losek edited a comment on Bug JENKINS-56997
I have also encountered this problem while upgrading jobs and Jenkins from an old version for core and plugin to latest ones (0.32). The same error and issues appeared for old jobs which should be migrated. But when I create a new job with same settings for GitHub multibranch it worked properly. When tried to copy old, broken to a new one (create new base on old one) error persist. When I downgraded plugin version to 0.31 old jobs which were migrated also started to work, so for my case, problems seems to be in the latest version of plugin (0.32) and old jobs. I also have basic auth in front of Jenkins but it's optional when accessing instance from trusted IPs and I've found that header Authorization was missing in requests, but error persisted.

So I think it's not only related with nginx reverse proxy behind Jenkins. Also I've encounted this problem while Scanning GitHub repository in jobs I could login to Jenkins which uses OAuth apps without problems.

Kind regards,
Marcin

sam.mxracer@gmail.com (JIRA)

unread,
Aug 6, 2019, 12:06:02 AM8/6/19
to jenkinsc...@googlegroups.com

I didn't realize the other issue was a dupe of this one. In any case, I'll close this as a dupe instead.

Fix released as https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/github-oauth/0.33/github-oauth-0.33.hpi

sam.mxracer@gmail.com (JIRA)

unread,
Aug 6, 2019, 12:06:18 AM8/6/19
to jenkinsc...@googlegroups.com
Sam Gleske closed an issue as Duplicate
 
Change By: Sam Gleske
Status: Open Closed
Resolution: Duplicate
Reply all
Reply to author
Forward
0 new messages