Bug 195473 - Permit authentication using API token
Permit authentication using API token
Status: RESOLVED FIXED
Product: connecteddeveloper
Classification: Unclassified
Component: Hudson
6.x
All All
: P2 (vote)
: 7.1
Assigned To: Jesse Glick
issues@connecteddeveloper
:
Depends on: 224586
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-14 21:41 UTC by pablopina
Modified: 2013-01-07 18:38 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments
Fruitless attempt to authenticate right from the start (2.30 KB, patch)
2011-09-21 21:13 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description pablopina 2011-02-14 21:41:47 UTC
Hi,

I am running netbeans 6.9.1 and when I try to add a hudson instance from cloudbees.com I get connection failed, as the instance requires user name and password authentication and netbeans doesnt show an auth challenge at any time, the connection fails. 

I tried encoding user name and password on the URL but netbeans doesnt seem to pick it up.

Detailed explanation here:




https://cloudbees.zendesk.com/entries/403545-connection-to-hudson-from-netbeans?page=1#post_609098
Comment 1 Jesse Glick 2011-02-14 22:42:19 UTC
NB does show an authentication dialog when connecting to a Hudson server if and when the server replies to a anonymous request with "403: Forbidden". Upon receiving login details, it posts them first to the login form needed for ACEGI security, and if that fails, to the container-based "legacy" authentication URL. Then it grabs the session cookie, deals with CSRF crumbs if enabled (after the fix of bug #193008), and retries the original request - all just as a web browser would do.

Perhaps the CB hosted instance relies on a nonstandard authentication mechanism? Can the problem be reproduced using a fresh Hudson installation?
Comment 2 pablopina 2011-08-30 10:29:02 UTC
Jesse,

Can you try connecting to cloudbees?

It doesn't seem to work.

https://cloudbees.zendesk.com/entries/403545-connection-to-hudson-from-netbeans


Will it be missing the --no-check-certificate option?

I can do a wget following this:

https://cloudbees.zendesk.com/entries/509885-accessing-your-jenkins-instance-using-http-basic-authentication-for-scripts-etc
Comment 3 kohsuke 2011-08-30 17:00:47 UTC
We've recently added the API token support so that client programs like NetBeans can reliably talk to the server, regardless of how the authentication mechanism is setup on the server. See http://blog.cloudbees.com/2011/08/api-token-in-jenkins-rest-api.html

While CloudBees don't deploy the version that has this support yet, I think going forward this is the proper way to handle this. It's simply impractical to expect NetBeans to deal with every different authentication mechanism out there.
Comment 4 Jesse Glick 2011-08-30 22:19:08 UTC
I am not sure what the purpose of the new API token is. Historical versions of Hudson/Jenkins already permit scripts to authenticate: if you attempt some operation which requires authentication to complete as anonymous, you are redirected to /j_acegi_security_check, which accepts an HTTP POST of credentials and then redirects back to the normal page after setting a session cookie which logs you in. This is what NetBeans uses, and while a bit cumbersome it works on all other H/J instances I know of except (apparently) those at Cloudbees.

So why does the CB installation not accept the regular ACEGI login mechanism? While it would be possible to implement a second org.netbeans.modules.hudson.spi.ConnectionAuthenticator using HTTP basic auth, I would rather avoid having to test an extra code path unless there is a reason why the usual authenticator cannot work. The existing authenticator cannot be removed any time soon, since it could be years before nearly all users have an installation supporting the new API token (even assuming it is ported to Hudson).

(Also "the server never solicits the authentication", contrary I think to normal HTTP basic auth usage, means even such an authenticator would be pretty awkward - you would not be prompted by the IDE to log in, but would have to remember to do so manually. Perhaps I am misunderstanding this comment.)

"The Java [...] standard libraries do not automatically parse out the username and password from the URL" - presumably this could be worked around in the client code, but storing your password in the connection URL is unacceptable anyway.
Comment 5 pablopina 2011-08-31 06:15:39 UTC
I don't know, maybe Koshuke can post a code snippet of how other IDEs do it...

Just as a teaser:

https://cloudbees.zendesk.com/entries/20279761-provide-ide-integration-with-netbeans




(In reply to comment #4)
> I am not sure what the purpose of the new API token is. Historical versions of
> Hudson/Jenkins already permit scripts to authenticate: if you attempt some
> operation which requires authentication to complete as anonymous, you are
> redirected to /j_acegi_security_check, which accepts an HTTP POST of
> credentials and then redirects back to the normal page after setting a session
> cookie which logs you in. This is what NetBeans uses, and while a bit
> cumbersome it works on all other H/J instances I know of except (apparently)
> those at Cloudbees.
> 
> So why does the CB installation not accept the regular ACEGI login mechanism?
> While it would be possible to implement a second
> org.netbeans.modules.hudson.spi.ConnectionAuthenticator using HTTP basic auth,
> I would rather avoid having to test an extra code path unless there is a reason
> why the usual authenticator cannot work. The existing authenticator cannot be
> removed any time soon, since it could be years before nearly all users have an
> installation supporting the new API token (even assuming it is ported to
> Hudson).
> 
> (Also "the server never solicits the authentication", contrary I think to
> normal HTTP basic auth usage, means even such an authenticator would be pretty
> awkward - you would not be prompted by the IDE to log in, but would have to
> remember to do so manually. Perhaps I am misunderstanding this comment.)
> 
> "The Java [...] standard libraries do not automatically parse out the username
> and password from the URL" - presumably this could be worked around in the
> client code, but storing your password in the connection URL is unacceptable
> anyway.

(In reply to comment #3)
> We've recently added the API token support so that client programs like
> NetBeans can reliably talk to the server, regardless of how the authentication
> mechanism is setup on the server. See
> http://blog.cloudbees.com/2011/08/api-token-in-jenkins-rest-api.html
> 
> While CloudBees don't deploy the version that has this support yet, I think
> going forward this is the proper way to handle this. It's simply impractical to
> expect NetBeans to deal with every different authentication mechanism out
> there.

(In reply to comment #4)
> I am not sure what the purpose of the new API token is. Historical versions of
> Hudson/Jenkins already permit scripts to authenticate: if you attempt some
> operation which requires authentication to complete as anonymous, you are
> redirected to /j_acegi_security_check, which accepts an HTTP POST of
> credentials and then redirects back to the normal page after setting a session
> cookie which logs you in. This is what NetBeans uses, and while a bit
> cumbersome it works on all other H/J instances I know of except (apparently)
> those at Cloudbees.
> 
> So why does the CB installation not accept the regular ACEGI login mechanism?
> While it would be possible to implement a second
> org.netbeans.modules.hudson.spi.ConnectionAuthenticator using HTTP basic auth,
> I would rather avoid having to test an extra code path unless there is a reason
> why the usual authenticator cannot work. The existing authenticator cannot be
> removed any time soon, since it could be years before nearly all users have an
> installation supporting the new API token (even assuming it is ported to
> Hudson).
> 
> (Also "the server never solicits the authentication", contrary I think to
> normal HTTP basic auth usage, means even such an authenticator would be pretty
> awkward - you would not be prompted by the IDE to log in, but would have to
> remember to do so manually. Perhaps I am misunderstanding this comment.)
> 
> "The Java [...] standard libraries do not automatically parse out the username
> and password from the URL" - presumably this could be worked around in the
> client code, but storing your password in the connection URL is unacceptable
> anyway.
Comment 6 Jesse Glick 2011-09-19 18:39:54 UTC
Closing until I can get some kind of response to comment #4 from Kohsuke or someone else knowledgeable about the Jenkins modifications (?) used by Cloudbees.
Comment 7 kohsuke 2011-09-21 17:02:36 UTC
The reason the API token mechanism is necessary is because there are various authentication implementations out there that do not depend on the use of password, such as OAuth, OpenID, Atlassian Crowd, and other SSO systems in general. CloudBees use one such SSO implementation, but otherwise it doesn't modify Jenkins in any non-standard way.

When Jenkins is configured with such SecurityRealm implementation, the client will not be redirected to /j_acegi_security_check, and instead it goes to some URLs that are highly protocol specific.

The API token mechanism allows users and tools to provide a consistent login mechanism regardless of the current authentication mechanism in place.

I'm reopening this as Jesse indicated that he closed this ticket until I provide a feedback.
Comment 8 Jesse Glick 2011-09-21 18:26:39 UTC
OK, I think I see the point now. Will try to prototype against https://builds.apache.org/ which seems to have the new facility available.
Comment 9 Jesse Glick 2011-09-21 20:40:44 UTC
Cannot seem to get it to work on builds.apache.org; I can supply basic auth via wget to start a job, but when I try the same from NetBeans, I get a 302 redirect to the home page and the job is not started. No idea what the problem is.

As an alternative, tried on a fresh local Jenkins installation with the OpenID plugin configured, with matrix security whereby authenticated has all perms and Anonymous has none. This works as expected; can log in via myopenid.com in the browser, then use Log In action in context menu of Jenkins instance in IDE, and then start a job. (Have to Cancel the initial dialog which requests a password, but then fill in the API token in the subsequent dialog.)
Comment 10 Jesse Glick 2011-09-21 21:12:12 UTC
Does not work with https://$user.ci.cloudbees.com/ since an unauthenticated initial "probe" request gets a redirect and no X-Hudson header:

HTTP/1.1 302 Moved Temporarily
Location: https://sso.cloudbees.com/sso-gateway/signon/login.do?josso_back_to=https://$user.ci.cloudbees.com/

Worse, this redirector is broken: the NB integration specifically tacks on a query string (?checking=redirects) to the initial request to see if it gets redirected to a location with the same query string, to ensure that various remote API functions will work even when there is a server redirect in place (bug #160508), but the above redirect URL has a different query string... in fact it discards the original query string entirely.

So trying to authenticate eagerly, on initial request. But first of all, https://$user.ci.cloudbees.com/user/$user/configure does not offer the API token, unlike regular Jenkins! The user has to manually navigate to https://$user.ci.cloudbees.com/configure instead. Or at least I am guessing that is the same "API token", but when I actually try it I still get a 401.

So sorry, cannot get CB connectivity to work. Maybe the CB devs can offer a patch, but I am out of ideas.
Comment 11 Jesse Glick 2011-09-21 21:13:18 UTC
Created attachment 110997 [details]
Fruitless attempt to authenticate right from the start
Comment 12 Jesse Glick 2011-09-21 21:19:16 UTC
(In reply to comment #10)
> https://$user.ci.cloudbees.com/user/$user/configure does not offer the API
> token, unlike regular Jenkins! The user has to manually navigate to
> https://$user.ci.cloudbees.com/configure instead. Or at least I am guessing
> that is the same "API token", but when I actually try it I still get a 401.

...and https://grandcentral.cloudbees.com/user/keys offers a _different_ API key, which does not work either. I also tried both my login name and email address as HTTP usernames.
Comment 13 Jesse Glick 2011-09-21 21:21:55 UTC
core-main #80f79262e051
Comment 14 Jesse Glick 2011-09-21 21:22:58 UTC
Should be implemented for vanilla Jenkins servers. Someone else can try to contribute a patch to make it work on CB too.
Comment 15 Jesse Glick 2011-09-21 21:30:49 UTC
Also filed: http://issues.hudson-ci.org/browse/HUDSON-9017
Comment 16 Quality Engineering 2011-09-22 14:49:49 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/80f79262e051
User: Jesse Glick <jglick@netbeans.org>
Log: #195473: Permit authentication using API token
Comment 17 pablopina 2011-11-14 15:16:32 UTC
(In reply to comment #16)
> Integrated into 'main-golden'
> Changeset: http://hg.netbeans.org/main-golden/rev/80f79262e051
> User: Jesse Glick <jglick@netbeans.org>
> Log: #195473: Permit authentication using API token

You are good man Jesse.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo