[JENKINS-6610] RSS Feeds Ought to Accept Credentials

[timja]

Under Manage Hudson/Configure System/"Security Realm" I've selected "Active Directory". Hudson is leveraging our organization's Active Directory for user authentication.

Under "Authorization" I use "Project-based Matrix Authorization Strategy".

I've found that RSS feeds require that the "Anonymous" user have Overall/Read and Job/Read permission in order for them to work. Even if the person accessing the feed has every permission checked, the RSS feeds won't work unless Anonymous has these two read permissions. This should not be so, since RSS readers are capable of passing credentials, and could pass the same credentials that the web browser does to authenticate with Hudson. For example, my RSS reader supports Basic, Digest and NTLM authentication schemes.

This enhancement request is for Hudson RSS feeds to accept passed credentials so that a Hudson installation does not have to be opened up to Anonymous in order for RSS feeds to work. Thanks.

---

Originally reported by williamleara, imported from: RSS Feeds Ought to Accept Credentials

• assignee: fbelzunc
• status: Open
• priority: Major
• resolution: Unresolved
• imported: 2022/01/10

[timja]

alghe:

Still valid for v1.576. This is very useful for admins that use a periodic fetch on Jenkins job status. For example if I develop Software I wouldn't like to be bombarded with notifications every 5 minutes, so the RSS aggregator (Akregator from KDE in my case) is configured to fetch every hour or so.

After enabling authentication this is no longer possible. Also it seems that Akregator's web browser is not able to login. It reports a bug in the login page script:

Error: http://jenkins:8080/login?from=%2F: TypeError: Attempt to use a non-function object or a value as a function.

Anonymous is denied all access (even read) so the only page you get is the login when you access it. I've tried through basic authentication in the form of the url but it fails (as it's so popularly documented on the web) and even with the API key I couldn't make much progress with regards to the RSS reader.

Too bad Jenkins is so powerful but yet so useless after you automate your infrastructure and you are poorly informed (or not at all) on whats going on; whats the point at this moment? Navigating from time to time to the page is not that nice when you only have a few minutes to take only a quick look.

My settings:

• Jenkins hosted on Ubuntu 12.04.4 LTS
  • Security policy:
    • Matrix per project (with Advanced Project plugin)
    • Users managed from Jenkins own database
    • No anonymous access is allowed
    • Several users configured (some are admins with full privileges, others are limited to their projects/views)

---

By the way williamleara what RSS reader are you using and on what O.S.?

[timja]

alghe:

Attached some screenshots (GNU/Linux Debian 7 with Akregator Version 1.6.6
Using KDE Development Platform 4.8.4 (4.8.4)):

• 1-akregator_jenkins-Cannot_Fetch_Feed.png – can't fetch the feed due to login
• 2-login_try-akregator_jenkins.png – trying to login via Akregator's browser
• 3-login_failed-akregator_jenkins.png – login failed and the supposed bug
• 4-akregator_jenkins.png – a sneak peek on how the announcements look; notice that the title is short and a link is provided, this is very useful when you just want to quickly know what is going on and if needed, go to the url (time is important)

[timja]

danielbeck:

Appears to be a client-side issue. I can get the feed from the command line using

curl --netrc http://jenkins/rssAll

if no anonymous access is allowed and the .netrc file contains my user name and API token.

Please demonstrate that the issue you're experiencing is not due to your RSS client being complete crap by providing output of the above (or similar, e.g. passing user name and API token directly on the command line) curl commands (alternatively wget) showing that the issue occurs there as well.

[timja]

alghe:

danielbeck:

Appears to be a client-side issue. I can get the feed from the command line using

curl --netrc http://jenkins/rssAll

if no anonymous access is allowed and the .netrc file contains my user name and API token.

And if the RSS client doesn't support this method? It's obvious people won't use curl to get their RSS.

Please demonstrate that the issue you're experiencing is not due to your RSS client being complete crap by providing output of the above (or similar, e.g. passing user name and API token directly on the command line) curl commands (alternatively wget) showing that the issue occurs there as well.

It's not because it has a web browser incorporated (KDE). Without enabling access to anonymous for viewing, I can't read the RSS (because it can't login, because of the login portal), however if I do enable, I can get RSS (as anonymous ofc. with privileges).

I do not exclude that the web browser of Akregator might be poor since I can login with ease with any other dedicated browser (Chrome, Mozilla Firefox etc.)

My guess is to make it compatible or add a &netrc= for the API token.
Tried various solutions around the internet with the API token but all failed at the login portal.

[timja]

danielbeck:

And if the RSS client doesn't support this method? It's obvious people won't use curl to get their RSS. ... My guess is to make it compatible or add a &netrc= for the API token.

To clarify, this is basic HTTP auth under the hood. --netrc just reads the username and password from a file rather than expecting username and password as parameters on the command line. I tested this just to be absolutely sure,

curl -u danielbeck:my_API_token http://jenkins/rssAll

works like a charm as well on an instance (Jenkins 1.565.2) without anon read access.

Hence my assertion that, if your RSS (HTTP) client cannot do basic HTTP authentication, that's not a problem of Jenkins.

[timja]

danielbeck:

Did you try the http://user:apitoken@jenkins/rssAll format for URLs with embedded authentication?

[timja]

williamleara:

As I mentioned in the original issue write-up:

my RSS reader supports Basic, Digest and NTLM authentication schemes

Being that is that case, and considering that multiple people are having the problem with a variety of RSS readers, this is not an RSS client issue.

[timja]

danielbeck:

Could you provide a log of the HTTP requests and responses sent by/to your RSS reader?

[timja]

danielbeck:

Does anyone get a failure to download the RSS feed with a curl or wget command? If so, please post the command and full (+debug) output.

[timja]

danielbeck:

I investigated this a bit.

The problem is that Jenkins sends the HTTP 403 header (Forbidden) when on the UI it shows a login form. Forbidden signals to the client that it's out of luck. So Basic auth only works when sent preemptively, without waiting for HTTP 401 asking for password.

Changing the response to HTTP 401 alone doesn't change anything. It requires sending a WWW-Authenticate header for it to work. When that is added, the RSS client (Vienna for OS X in my case) suddenly starts working. Unfortunately, then web browsers display the regular basic login form in addition to the login form, which isn't desirable.

Possible options (besides adding preemptive auth to RSS clients) include:

• Distinguish response by whether it would be RSS? Not possible reliably
• Browser sniffing, send WWW-Authenticate if it's not a known web browser (or if it's a known RSS reader)? Not possible reliably
• Make RSS feeds reachable via UnprotectedRootAction that implements its own authentication and can send WWW-Authenticate without breaking interactive clients, a bit like Build Token Root Plugin allows unauthenticated clients to build when the remote trigger token is known. But how to determine which is the RSS URL called that way?
• Add something to requests that should result in HTTP 401 + WWW-Authenticate. A parameter ?basic comes to mind, but that's not a great solution.

[timja]

danielbeck:

Opened https://github.com/jenkinsci/jenkins/pull/1415 for discussion.

[timja]

jglick:

Assuming that simply encoding the username and API token in the URL is undesirable for security reasons, I tend to like the idea of using a 401 when the client has not specified that it will Accept: text/html.

[timja]

[Originally depends on: JENKINS-26468]