| Summary: | Hudson Connector - AuthenticationException: Forbidden | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Sebastian List <basti> |
| Component: | Mylyn | Assignee: | 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.1 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=372596 | ||
| Whiteboard: | |||
|
Description
Sebastian List
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 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. 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. 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
PS: I used Chrome extension 'REST Console' to send those requests to the server manually if that matters. 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. :) 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. 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 I can indeed confirm that it works if you uncheck the "CSRF Protection" under Global secutiry settings. 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 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 |