Bug 195473

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?

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

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.

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.

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.

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.

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.

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.

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.)

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.

Created attachment 110997 [details]
Fruitless attempt to authenticate right from the start

(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.

core-main #80f79262e051

Should be implemented for vanilla Jenkins servers. Someone else can try to contribute a patch to make it work on CB too.

Also filed: http://issues.hudson-ci.org/browse/HUDSON-9017

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

(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.