Authentication failing

[scarabx@…]

Hi,

I get the following output on the Timeline when I try to access my Hudson instance:

Event provider HudsonTracPlugin failed for filters "Hudson Builds": IOError: Error getting build info from
'http://myserver.com/hudson/job/ajob/api/xml?
xpath=/*/build[timestamp>=1275796799000][timestamp<=1278475199000]&depth=1&exclude=//action|//artifact|//changeSet|//culprit&wrapper=builds': 
HTTPError: HTTP Error 404: Not Found. This most likely means you configured a wrong job_url.

The HudsonTracPlugin is configured with the following:

job_url = http://myserver.com/hudson/job/ajob/
main_page = http://myserver/hudson/
username = theusername
password = thepassword

I have hudson configured to use access control with:

Security Realm = Hudson's own user database
Authorization = Project-based Matrix Authorization Strategy

The user I have setup in HudsonTrac plugin has the following perms setup in Hudson:

Overall: read
Job: Create, Configure, Read, Build, Workspace

My current setup is:

HudsonTrac Plugin v0.3
Hudson v1.365

[anonymous]

I don't think this has anything to do with authentication - are you sure the job_url you configured is correct? What happens if you try to access that url using your browser?

[scarabx@…]

Replying to anonymous:

I don't think this has anything to do with authentication - are you sure the job_url you configured is correct? What happens if you try to access that url using your browser?

When I try the job url in the browser I get the following error page from Tomcat 6:

HTTP Status 404 -
type Status report
message
description The requested resource () is not available.

That seems reasonable since anonymous does not have "Read" permission for Jobs in my Hudson setup. However, the user I setup in the HudsonTrac plugin does have "Read" permission for Jobs, so it seems the plugin is not using the username and password credentials when fetching the data.

[orio]

Hello,

I have the same output with Trac 0.11, HudsonTrac Plugin v0.3, and Hudson 1.367. The plugins seems to make an unauthenticated query to hudson.

An wget query to my hudson instance produces this HTTP query:

GET /hudson/job/myjob/api/xml HTTP/1.0
User-Agent: Wget/1.12 (linux-gnu)
Accept: */*
Authorization: Basic blahblah
Host: myhost
Connection: Keep-Alive

and the reply is correct whereas, the Hudson Trac Plugin produces this, leading to a 404 error:

GET /hudson/job/myjob/api/xml?<snip> HTTP/1.1
Accept-Encoding: identity
Host: myhost
Connection: close
User-Agent: Python-urllib/2.5

So I think the plugin clearly does not send the credential.

[roadrunner]

Something's messed up: a 404 response code means that the resource is not there; period. When a resource requires authentication, Hudson will send a 403 (which contains a meta-refresh to redirect to the login page). And the plugin will only send the auth info if it receives that 403.

The fact that you're getting a 404 indicates something isn't configured correctly - are you saying that both your wget and the request sent by the plugin are A) really for the same URL, B) both get a 404 when you don't supply auth-info, but C) the wget works if you do supply that auth-info? I just tried it locally again with the project-based matrix auth and the same controls you describe, and I get the 403 as expected.

[anonymous]

• A) Yes, it's for the same URL
• B) Yes too, if no auth-info are supplied, we receive a 404. This error appears either through Apache2 + mod_jk or directly by asking Hudson on port tcp:8080

  Status Code: 404
  Exception:
  Stacktrace:
  
  (none)
  
  
  Generated by Winstone Servlet Engine v0.9.10 at Mon Sep 06 13:39:52 CEST 2010
  

• C) Here is an example of the output, with a project-based matrix auth too, our instance of Hudson is plugged with an OpenLDAP server.
  • With no-auth

    curl "http://localhost/hudson/job/myproject/api/xml?xpath=/*/build\[timestamp%3E=1281131999000\]\[timestamp%3C=1283810399000\]|/*/module/build\[timestamp%3E=1281131999000\]\[timestamp%3C=1283810399000\]&depth=2&exclude=//action|//artifact|//changeSet|//culprit&wrapper=builds"
    <html><head><title>Error 404</title></head><body bgcolor="#ffffff"><h1>Status Code: 404</h1>Exception: <br>Stacktrace: <pre>(none)
    </pre><br><hr size="1" width="90%"><i>Generated by Winstone Servlet Engine v0.9.10 at Mon Sep 06 13:55:01 CEST 2010</i></body></html>
    

  • With auth

    root@hudson:~# curl -H 'Authorization: Basic <blahblah>' "http://localhost/hudson/job/myproject/api/xml?xpath=/*/build\[timestamp%3E=1281131999000\]\[timestamp%3C=1283810399000\]|/*/module/build\[timestamp%3E=1281131999000\]\[timestamp%3C=1283810399000\]&depth=2&exclude=//action|//artifact|//changeSet|//culprit&wrapper=builds"
    <builds><build><building>false</building><duration>115305</duration><fullDisplayName>myproject #288</fullDisplayName><id>2010-09-01_17-43-58</id><keepLog>false</keepLog><number>288</number><result>SUCCESS</result><timestamp>1283355838597</timestamp> <...> </build></builds>
    

I tried unplugging the OpenLDAP connexion, the result is the same except for the authenticated request leading to a 401.

[roadrunner]

Replying to anonymous:

• C) Here is an example of the output, with a project-based matrix

auth too, our instance of Hudson is plugged with an OpenLDAP server.

Ah, you're using LDAP - I think that's the issue. See also ​HUDSON-4748.

I tried unplugging the OpenLDAP connexion, the result is the same except for the authenticated request leading to a 401.

Which would be the correct response code, if Hudson were using HTTP-Authentication. But isn't :-( .

[anonymous]

Ah, you're using LDAP - I think that's the issue. See also HUDSON-4748.

Yes, it may be that.

Which would be the correct response code, if Hudson were using HTTP-Authentication. But isn't :-(

Not right, that is a correct behavior, because if I unplug my OpenLDAP, my user becomes invalid. So the 401 is correct.

I'm on a LAN only environnement, so I can use Apache2's SetEnvIf and mod_headers to 'auto' authenticate request coming from my Trac instance to my Hudson to bypass this auth issue.

SetEnvIf Remote_Addr "A\.B\.C\.D" tracrequest
RequestHeader set Authorization "Basic <...>" env=tractrequest

Now since it is not a really a plugin related issue, I let you decide how you will handle this case (maybe a warning in the documentation installation or a special option to force auth to be send) :)

[simon.haegler@…]

i have the same issue, the reported url in the error message works correctly in a browser... (i use unix auth in hudson). is there anybody working on it? how can i help?

[roadrunner]

Replying to simon.haegler@procedural.com:

i have the same issue, the reported url in the error message works correctly in a browser... (i use unix auth in hudson). is there anybody working on it? how can i help?

Thanks for the offer. If you can figure out why Hudson is sometimes sending a 404 instead of a 403 and fix Hudson to always send a 403, that would be great.

[Lars Skjærlund]

I have exactly the same problems as the rest: The plugin doesn't authenticate.

Hudson/Jenkins does respond with a 404 when that happens - I know it means "Page does not exist", but it is a quite common security measure to do just that: Claim that a page doesn't exist when you're not allowed to see it - even though it's there.

Changing security settings on Hudson/Jenkins to allow the anonymous user to access the page does make the plugin work - but compromises security, of course.

We're using Jenkins 1.409.1 on Windows (the LTS release) with the Active Directory plugin.

[anonymous]

Same problem here on Hudson 1.396 and trac 0.11.

When security is tight, the plugin fails. Copying the url (exactly the same) to a browser while logged into Hudson provides the expected python results.

When security is set to allow anonymous reading of jobs for that project, the plugin works as expected.

[roadrunner]

(In [11432]) Add support for API Token introduced in Jenkins 1.426.

This closes #7340 and #9507.