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.

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.

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.

Add Comment

This ticket has been modified since you started editing. You should review the
other modifications which have been appended above,
and any conflicts shown in the preview below.
You can nevertheless proceed and submit your changes if you wish so.