Modify

Opened 4 years ago

Closed 2 years ago

#7340 closed defect (fixed)

Authentication failing

Reported by: scarabx@… Owned by: roadrunner
Priority: high Component: HudsonTracPlugin
Severity: major Keywords:
Cc: Trac Release: 0.11

Description

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

Attachments (0)

Change History (12)

comment:1 follow-up: Changed 4 years ago by 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?

comment:2 in reply to: ↑ 1 Changed 4 years ago by 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.

comment:3 Changed 4 years ago by 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.

comment:4 Changed 4 years ago by 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.

comment:5 follow-up: Changed 4 years ago by 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.

comment:6 in reply to: ↑ 5 Changed 4 years ago by 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 :-( .

comment:7 Changed 4 years ago by 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) :)

comment:8 follow-up: Changed 4 years ago by 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?

comment:9 in reply to: ↑ 8 Changed 4 years ago by 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.

comment:10 Changed 3 years ago by larsskj

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.

comment:11 Changed 3 years ago by anonymous

  • Trac Release changed from 0.12 to 0.11

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.

comment:12 Changed 2 years ago by roadrunner

  • Resolution set to fixed
  • Status changed from new to closed

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

This closes #7340 and #9507.

Add Comment

Modify Ticket

Action
as closed .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from roadrunner. Next status will be 'closed'.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.