Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 412596

Summary: Hudson Connector - AuthenticationException: Forbidden
Product: z_Archived Reporter: Sebastian List <basti>
Component: MylynAssignee: Project Inbox <mylyn-triaged>
Status: CLOSED MOVED QA Contact:
Severity: major    
Priority: P2 CC: basti, manderse, mattias.bergander, mthompson, sam.davis, SchubertCh, steffen.pingel, wayne.beaton
Version: 1.1Keywords: helpwanted
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=372596
Whiteboard:

Description Sebastian List CLA 2013-07-09 11:17:36 EDT
Hi,
I experiencing authentication errors when trying to connect to a Hudson v3.0.0 server. I cannot refresh Build Plans, nor can I validate my settings. The Stacktrace reads as follows:

org.eclipse.core.runtime.CoreException: Unexpected error: Forbidden
	at org.eclipse.mylyn.internal.hudson.core.HudsonCorePlugin.toCoreException(HudsonCorePlugin.java:61)
	at org.eclipse.mylyn.internal.hudson.core.HudsonServerBehaviour.validate(HudsonServerBehaviour.java:908)
	at org.eclipse.mylyn.builds.internal.core.BuildServer.validate(BuildServer.java:369)
	at org.eclipse.mylyn.builds.ui.spi.BuildServerPart$Validator.run(BuildServerPart.java:114)
	at org.eclipse.mylyn.commons.repositories.ui.RepositoryLocationPart$2.run(RepositoryLocationPart.java:558)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Caused by: org.eclipse.mylyn.internal.hudson.core.client.HudsonException: Forbidden
	at org.eclipse.mylyn.internal.hudson.core.client.HudsonOperation.run(HudsonOperation.java:169)
	at org.eclipse.mylyn.internal.hudson.core.client.RestfulHudsonClient.validate(RestfulHudsonClient.java:412)
	at org.eclipse.mylyn.internal.hudson.core.HudsonServerBehaviour.validate(HudsonServerBehaviour.java:902)
	... 4 more
Caused by: org.eclipse.mylyn.commons.repositories.core.auth.AuthenticationException: Forbidden
	at org.eclipse.mylyn.internal.hudson.core.client.HudsonOperation.validate(HudsonOperation.java:273)
	at org.eclipse.mylyn.internal.hudson.core.client.HudsonOperation.authenticate(HudsonOperation.java:89)
	at org.eclipse.mylyn.commons.repositories.http.core.CommonHttpOperation.executeOnce(CommonHttpOperation.java:114)
	at org.eclipse.mylyn.commons.repositories.http.core.CommonHttpOperation.execute(CommonHttpOperation.java:74)
	at org.eclipse.mylyn.internal.hudson.core.client.RestfulHudsonClient$8.execute(RestfulHudsonClient.java:390)
	at org.eclipse.mylyn.internal.hudson.core.client.RestfulHudsonClient$8.execute(RestfulHudsonClient.java:1)
	at org.eclipse.mylyn.internal.hudson.core.client.HudsonOperation.run(HudsonOperation.java:167)
	... 6 more

The setup:
- SSL secured Hudson (v3.0.0), no anonymous access allowed
- Hudson behind a proxy server

What I found out:
Using Fiddler as a reverse proxy, it appears that the connector sends 2 POST requests to <hudsonURL>/j_acegi_security_check with Content-Type: application/x-www-form-urlencoded. It gets a HTTP/1.1 403 Forbidden response on both requests. The only difference between them is that in the first response a JSESSIONID and a Path cookie are set.
So in fact, the Hudson v3 URL j_spring_security_check is NOT requested. (I read the src at https://eclipse.googlesource.com/mylyn/org.eclipse.mylyn.builds/+/master/org.eclipse.mylyn.hudson.core/src/org/eclipse/mylyn/internal/hudson/core/client/HudsonOperation.java)

I don't know what the expected behavior is, but the Hudson Wiki says: (http://wiki.hudson-ci.org/display/HUDSON/Authenticating+scripted+clients)
"To make scripted clients (such as wget) invoke operations that require authorization (such as scheduling a build), use HTTP BASIC authentication to specify the user name and the password. This is often more convenient than emulating the form-based authentication.
Note that Hudson (at least when installed on a Debian server with apt-get) does not do any authorization negotiation. Ie. it immediately returns a 403 (Forbidden) response instead of a 401 (Unauthorized) response, so make sure to send the authentication information from the first request."

So I suggest using HTTP Basic Auth instead of the form emulation if this leads to the error.

I think that SSL + proxy is not a problem here since I see both request and response decrypted in Fiddler's output, I just mentioned it just in case. By the way, connection to a SSL-secured Jenkins 1.500 (through proxy again) worked without any problems.

The Mylyn versions are stable releases from 20130612, in detail:
  Mylyn Builds Connector: Hudson/Jenkins	1.1.0.v20130612-0100	org.eclipse.mylyn.hudson.feature.group	Eclipse Mylyn
  Mylyn Commons	3.9.0.v20130612-0100	org.eclipse.mylyn.commons.feature.group	Eclipse Mylyn
  Mylyn Commons Identity	1.1.0.v20130612-0100	org.eclipse.mylyn.commons.identity.feature.group	Eclipse Mylyn
  Mylyn Commons Notifications	1.1.0.v20130612-0100	org.eclipse.mylyn.commons.notifications.feature.group	Eclipse Mylyn
  Mylyn Commons Repositories	1.1.0.v20130612-0100	org.eclipse.mylyn.commons.repositories.feature.group	Eclipse Mylyn
  Mylyn Commons Repositories HTTP Transport	1.1.0.v20130612-0100	org.eclipse.mylyn.commons.repositories.http.feature.group	Eclipse Mylyn
  Mylyn Context Connector: Eclipse IDE	3.9.0.v20130612-0100	org.eclipse.mylyn.ide_feature.feature.group	Eclipse Mylyn
  Mylyn Context Connector: Java Development	3.9.0.v20130612-0100	org.eclipse.mylyn.java_feature.feature.group	Eclipse Mylyn
  Mylyn Context Connector: Team Support	3.9.0.v20130612-0100	org.eclipse.mylyn.team_feature.feature.group	Eclipse Mylyn
  Mylyn Task List	3.9.0.v20130612-0100	org.eclipse.mylyn_feature.feature.group	Eclipse Mylyn
  Mylyn Task-Focused Interface	3.9.0.v20130612-0100	org.eclipse.mylyn.context_feature.feature.group	Eclipse Mylyn
  Mylyn Tasks Connector: Mantis	3.10.0.201305262021	com.itsolut.mantis_feature.feature.group	ITSOLUT
  Mylyn WikiText	1.8.0.v20130612-0100	org.eclipse.mylyn.wikitext_feature.feature.group	Eclipse Mylyn
Comment 1 Sebastian List CLA 2013-07-15 08:09:04 EDT
P.S.:
Jenkins also recommends using HTTP Basic Auth, though not the User Password used for BASE64-encoding the credentials but the user-specific API-token. Nevertheless, it's HTTP Basic Auth and NOT emulation of HTML forms.
see https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients
Comment 2 Sebastian List CLA 2014-02-04 09:05:38 EST
Did anything happen in the last half of a year? I would still appreciate the ability to control Hudson build from within Eclipse.

My recommendation is to use HTTP Basic Authentication. I wrote a script since than and it perfectly works for Hudson.
For Jenkins it would be enough to add a note to the UI that the API-token should be provided instead of the user password. Alternatively, the existing approach could remain in the code since it appears to be working with Jenkins.
Comment 3 Sam Davis CLA 2014-02-06 19:39:33 EST
Thanks for the detailed bug report! It looks like the problem is that your server is not returning a 404 for /j_acegi_security_check - could you confirm what response you get when doing a GET to that URL? It's only when getting a 404 there that the connector tries /j_spring_security_check. Since we no longer support versions prior to 3.0.1 we should probably try the latter first and fall back to the former if it fails: https://git.eclipse.org/r/#/c/21655/. This appears to still work for Hudson 2.2.1.
Comment 4 Sebastian List CLA 2014-02-07 12:05:03 EST
When sending a GET to /j_acegi_security_check, I receive the following answer using Hudson 3.0.0:

Status Code: 403
Date: Fri, 07 Feb 2014 16:54:18 GMT
Server: Apache/2.2.12 (Linux/SUSE)
Connection: Keep-Alive
Keep-Alive: timeout=15, max=100
Transfer-Encoding: chunked
Content-Type: text/html;charset=UTF-8

<html><head><meta http-equiv='refresh' content='1;url=/hudson/login?from=%2Fhudson%2Fj_acegi_security_check'/><script>window.location.replace('/hudson/login?from=%2Fhudson%2Fj_acegi_security_check');</script></head><body style='background-color:white; color:white;'>Authentication required</body></html>

Doing that request authenticated (providing an Auth header) returns a 404.

A request (unauthenticated) to /j_spring_security_check returns a 401, stating in the body that my credentials are not valid.

An authenticated one to that URL returns a 200 and the Overview page.

I still don't really understand why the connector cannot provide that Authorization header with every request. Isn't that simpler overall? Though the change set might be bigger in the first place..

BR
Comment 5 Sebastian List CLA 2014-02-07 12:06:25 EST
PS: I used Chrome extension 'REST Console' to send those requests to the server manually if that matters.
Comment 6 Sam Davis CLA 2014-02-14 16:52:50 EST
Thanks. It sounds like providing the auth header might be a better solution, but it will be a while before we have time to look into that. It could help to speed this up if you submitted a code review. :)
Comment 7 Max Rydahl Andersen CLA 2014-08-27 15:47:21 EDT
anyone know what the cause of this is ? 

I got two password protected jenkins servers - one it works on the other get the same issue like this.
Comment 8 Christian Schubert CLA 2015-01-09 09:37:23 EST
Maybe there is again a problem with the crumb security feature to prevent CSRF attacks. Because when i disable the checkbox "Prevent from Cross Site Request Forgery" attacks in Jenkins global settings it seems to be working.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=355927
Comment 9 Mattias Isegran Bergander CLA 2019-02-05 11:06:14 EST
I can indeed confirm that it works if you uncheck the "CSRF Protection" under Global secutiry settings.
Comment 10 Michael Thompson CLA 2020-07-15 12:40:54 EDT
Still happening with the latest connector and Jenkins.  You can still disable CSRF (for now) with a system property but it looks like that might go away in the future.

https://www.jenkins.io/doc/upgrade-guide/2.222/#always-enabled-csrf-protection
Comment 11 Eclipse Webmaster CLA 2022-11-15 11:45:08 EST
Mylyn has been restructured, and our issue tracking has moved to GitHub [1].

We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub.

[1] https://github.com/orgs/eclipse-mylyn