[DO NOT MERGE] [JENKINS-6610] Allow clients to request HTTP 401/WWW-Authenticate

[daniel-beck]

Do not merge, but please share your thoughts on this.

---

Non-browser clients currently have the problem that they don't get a proper basic auth challenge from Jenkins for access to a restricted resource: It's just HTTP 403 Forbidden, and a redirect to the login form.

OTOH if Jenkins sends the HTTP 401 response and WWW-Authenticate header, web browsers will start showing the login popup window for basic authentication.

Would a solution like this one be acceptable? RSS clients would then need to start requesting e.g. /rssAll?basic to get a proper challenge, if they don't support preemptive authentication. A simple reconfiguration should do it, and for future users all links to RSS feeds on the UI could be changed.

I considered a few other solutions in a recent comment to JENKINS-6610, but all of them seem worse than this.

[fbelzunc]

@daniel-beck Is not enough good the solution you suggest here?

[ndeloof]

IMHO a better option would be for a servlet filter to check URI is used for user interaction vs API access : anything /api/*, /rss* and few other would then get WWW-Authenticate header set as expected for basic authentication. Maybe an even better way would be for stapler to handle this based on some annotation on related resource

[fbelzunc]

@daniel-beck If you don't plan to work on this, I will be happy to start.

[daniel-beck]

@fbelzunc As I wrote, this is only request for comments. Feel free implement this properly, a solution is clearly needed. @ndeloof brings up a few good points as well.

[cyrille-leclerc]

Few ideas:

• If a http header Authorization exists in an anonymous HTTP request, then Jenkins should try to authenticate the user with this Authentication header
• The logic to choose the authentication mechanism (302 redirect to a web form...) should evaluate to HTTP header Accept of the HTTP request and could initiate a basic auth if Accept do not mention html