Permissions and RSS Feeds

[anonymous]

When you have "View Tickets" protected by REPORT_VIEW permission, it makes subscribing to the RSS feed difficult using the available tools. Most tools are able to handle an http authentication step.

While my experience is specifically with the Ticketing Report system, this bug applies to any area guarded by a permission that provides an RSS feed.

The primary use case for this is for a developer (Me ;) subscribing to the RSS feed of a "My Tickets" report.

[cmlenz]

This is a good point.

I wonder whether we could simply redirect unauthenticated users to the /login URL instead of generating a "permission denied" error page. The /login URL would then simply redirect to the page originally requested, as it does anyway.

[anonymous]

Shouldn't you generate an appropriate HTTP error code that will tell the RSS feed reader to send credentials?

[cmlenz]

That's what would happen if we redirected to /login (which would then redirect back to the RSS feed).

[daniel]

This becomes even more difficult when there's a session stored, and Trac stops to tell you the session need authentication.

[daniel]

cmlenz: interesting issue... no easy solution
#540 is tough as of now... 
cmlenz: the iCalendar support has the same issue BTW
i say redesign the whole rss stuff in 2.0
cmlenz: I hacked around it
* dln 'd like to have a single rss resource responsible for all rss feed
cmlenz: ah, "project summary" 
like http://p.e.c/trac/rss/report/1 or http://p.e.c/trac/rss (timeline) or http://p.e.c/trac/rss/user/dln
and likewise... http://p.e.c/trac/icalendar/foo/bar
generally going more REST-style overall
but i digress... #540 is a 2.0 sweetspot imho

[anonymous]

Why can't we get a simple fix for this? Why does it have to pull the $USER variable from the logged in user. Can't it just pull the variable from $_GET ? does it really need authentication? Any unauthenticated can see all other reports, including a custom report for a certain plugin, but there is no rss for that and you have to be logged in for that too. I would love to be able to get my new reports in my aggregator instead of having to check back every day.

What is the timeline for 2.0? 2006?

[mgood]

The USER variable is already added as a URL parameter to the Reports RSS feed links. This is fine as long as "anonymous" has the REPORT_VIEW permission. It doesn't matter if someone can set USER to the name of someone else, since anyone is allowed to view the reports.

However, the problem under discussion here is how to handle the authentication when "anonymous" can't view the report. So, authentication is required, or this would be a big security hole that would allow anyone to access RSS feeds on a site that did not allow anonymous access.

[mgood]

#1405 has been marked as a duplicate of this ticket

[mladen@…]

How about setting a PASSWORD parameter to the url too? And then authenticate if it's available? This might be a little hole, but it really is an irritating bug.

[mgood]

The password parameter will not work since Trac itself has no knowledge of your authentication scheme. The authentication is handled by Apache, so besides the poor security implications of passing the password like that, it would be of little use to Trac.

[thijs@…]

A quick fix for 1.0 would be greatly appreciated; the RSS feeds are currently completely useless when you require anything other than anonymous access.

How about allowing access to all resources in Trac using only the authentication information provided by Apache when the url is prefixed with /login? In this case, the http authenticated version of:

/timeline?daysback=90&max=50&format=rss

would simply be:

/login/timeline?daysback=90&max=50&format=rss

I suspect this would be not that hard to implement, and it would be kind of a hack, but it would at least allow proper user of the feeds.

[Alexander Shopov <ash@…>]

#1767 is a duplicate of this issue.

[cmlenz]

#1238 has been marked as duplicate of this ticket. It raises the same concern, but about the iCalendar view of the roadmap.

[cmlenz]

#1951 has been marked as duplicate of this ticket.

[Pedro Melo <melo-trac-tickets@…>]

This problem is present on other webtools I use. Also, I think that dealing with 403 HTTP error codes (auth required) is more common than dealing with redirects on current RSS aggregators.

I think that the /login/timeline solution presented above is the best hack than we can have until the system is redesigned. Does anybody has a patch for that?

Thanks,

[Pedro Melo <melo-trac-tickets@…>]

Ok, got a workable workaround :)

I'm using the Global Authentication recipe at wiki:TracMultipleProjects#Globalauthentication. If you change the last <LocationMatch> from

<LocationMatch "/projects/[[:alnum:]]+/login">

to

<LocationMatch "/projects/.*">

then all the URL's are now protected with basic auth, and that means that the RSS and iCal URL's will require basic auth.

At least with my RSS aggregator, NetNewsWire, I'll get the correct username/password prompt.

Hope this helps.

[osimons]

My solution was to use Apache LocationMatch as well. However, it was not an option to enforce it on the whole /projects directory (and all purposes in all projects) as I want to use Trac permissions to decide what anonymous users can view in each project.

Here is my directive, slightly modified to separate the RSS logic from the rest of the config by adding this LocationMatch for this purpose only:

<LocationMatch /projects/[[:alnum:]]+/+[*format=rss*|timeline?*]>
     AuthType Basic
     AuthName "MyProjects"
     Require valid-user
     .....
</LocationMatch>

This then enforces http login for all the URLs containing the RSS feeds for my purpose. However, I notice there are other things like iCalendar and so on that I don't use - but should easily be added to the OR structure above.

What would be useful is to standardise the URLs/parameters for RSS feeds (and other specialised formats), so that a simple *format=RSS* would catch all occurences - many do, but notably Timeline use something else.

[osimons]

No....

I have to recall my previous comment... Some missing research on my part, unfortunately.

1. The above <LocationMatch> directive will not work as intended. The problem is that the <LocationMatch> directive does not look at the query string as part of the URL.
2. My regular expression is not very good - not good at all in fact... Have been reading up on it a bit more since posting, and it really doesn't make sense!
3. The last error on my part is that the timeline does include the "format=rss" parameter in the query string - I wasn't looking hard enough... As far as I have been able to find, all rss feeds supports this pattern.

Quite a number of hours have been spent on this, and as far as I can tell there is no other workaround other than to enforce authentication for all of /projects.

Hopefully someone will present a solution soon - it is a very important issue.

[rocha]

Actually, LocationMatch may be appropiate for some:

<LocationMatch /tracproject/(login|timeline)>
     AuthType Basic
     AuthName "Trac Project"
     Require valid-user
     .....
</LocationMatch>

It will still let anonymous users browse according to their permissions, while allowing authorized users to access the appropiate rss feed. The only side effect is that authorized users could login clicking timeline instead of login.

Can anyone confirm if this works?

[Hervé Leroux]

Seems to work rocha Thanks Rv

[cmlenz]

#2607 has been marked as dupe of this ticket.

[kyle@…]

It is kind of frustrating to see that this has been a problem for 2 years. Seeing it pushed off to 0.8, 1.0, now 2.0 is even more frustrating, it sounds a lot like "never". Yet as it is now, the RSS appears to be useless for non-public projects. It seems like a good solution was discussed above, of making it return an HTTP authorization flag instead of redirecting to the unhelpful "need rights" page. Then common RSS readers (which handle pages requiring authorization for lots of other web-app RSS feeds, no problem) would work here.

But I hate it when people whine about a desired feature on an open source project.

I am not in a position to work on it personally, but is there something my firm can do, to "sponsor" getting a solid solution to this in the next version of Trac?

[anonymous]

Hello, I found (and use) a client-side workaround, which at least works with Thunderbird 1.5.0.5 (20060719) (German Edition), to solve the problem discussed here:

I let Thunderbird check the following (sample) URL for a RSS feed, first... http://username:password@trac.something.com/myproject/login

...then, I let Thunderbird check the correct feed at http://trac.something.com/myproject/timeline?milestone=on&ticket=on&changeset=on&wiki=on&max=50&daysback=90&format=rss

When checking the first URL, Thunderbird complains about not finding a valid RSS feed (of course). Nevertheless, it accepts (and stores) the "trac_auth" cookie that is needed to access the second (real) RSS feed. To make this work, of course, the user preference "network.cookie.cookieBehavior" must be set correctly (either to "0" or to "3"). Have a look at "Tools" - "Options" - "Advanced" - "General" - "Config Editor" - Filter "cookie" >> "network.cookie.cookieBehavior" (in German: "Extras" - "Einstellungen" - "Erweitert" - "Allgemein" - "Konfiguration bearbeiten" - Filter "cookie" >> "network.cookie.cookieBehavior") to check on that.

I let Thunderbird collect the news of both feeds into the same folder. I added the feeds to that folder in a particular order (via "Tools" - "Account Settings" - choose your RSS account - "Manage Subscriptions" - "Add" - "Store Articels in" - your folder; in German: "Extras" - "Konten" - your RSS account - "Verwalte Abonnements" - "Hinzufügen" - "Speichere Artikel in" - your folder; create the folder first (!) via "File" - "New" - "Folder" - "Create as Subfolder of" - your RSS account; in German: "Datei" - "Neu" - "Ordner" - "Erstellen als Unterordner von" - your RSS account)

1. http://username:password@trac.something.com/myproject/login,
2. http://trac.something.com/myproject/timeline?...&format=rss

So, all I need to do now is select that folder and press F5... and then, I can pull the feed and view its contents (at least, all contents that I have the view-permisson for)... :-)

Maybe this is of use for anybody else...

Many cheers, nik4536.

[anonymous]

Sorry for bothering again (and I know, this is off topic!). However, I noticed that Thunderbird evaluates ONLY the <link>...</link> field of any RSS feed item. As a result, two (or more) changes to the same wiki page (for example) show as one!! To overcome this, I modified the <link>...</link> field in the .../share/trac/templates/timeline_rss.cs file as follows:

<link><?cs var:event.href + '#' + event.date ?></link>

This is dirty (arghhh!), but it works (at least with Thunderbird and Firefox)...

Best would be, of course, to use the <guid>...</guid> field to do the same, e.g.

<guid isPermaLink="false"><?cs var:event.href + ' changed on ' + event.date ?></guid>

However, Trac does not transmit it (why not, btw?), and Thunderbird does not evaluate it :-(...

nik4536

[anonymous]

me again... a colleague of mine and I implemented a patch which permits to add http login functionality to every Trac page... It's pretty much what was proposed previously by thijs@… on 06/23/05 17:45:28 (i.e. using a http redirect). Have a look at http://trac-hacks.org/wiki/HttpLoginViaRedirectPatch to download and install the patch.

Furthermore, we solved the (off-topic) Thunderbird problem - i.e. we added a guid element to Trac's Timeline RSS Feed (find out more about it at http://trac.edgewall.org/ticket/3167) and made Thunderbird evaluate this guid element properly (see http://dawis2.icb.uni-due.de/jpddtools/RssItemUniqueUriPatch.html).

Hope this helps...

nik4536

[Jorge <jorge.vargas@…>]

hi nik4526 I believe your patch is broken agains 0.10 because I can't get it to work, there is a ticket in trac-hacks agains it with a patch that isn't working for me either :(

why is this on milestone 2.0? that almost seems like WONTFIX at the moment. trac is used in a lot of closed environments and I'm sure a lot of people don't use RSS because of this,

why can't nik's patch be applied to trunk?

[jan.vornberger@…]

Another workaround: I use the standalone trac server and since basically everything is password protected for our project, I simply patched the authentication code in such a way, that it _always_ asks for a password. Simple hack, that I just wanted to share it, in case it might be a possible workaround for others.

Replace this line (line 47) in .../python2.4/site-packages/trac/web/standalone.py

if len(path_parts) > self.part and path_parts[self.part] == 'login':

with this one

if len(path_parts) > 0:

Regards, Jan

[anonymous]

yet one way to resolve this issue would be to implement random private (secret) rss url suffixes that would thus contain authentication in themselves. I suspect this would be sufficient for majority of users. I believe google uses this mechanism to share private calendars or something.

[nkantrowitz]

Replying to anonymous:

yet one way to resolve this issue would be to implement random private (secret) rss url suffixes that would thus contain authentication in themselves. I suspect this would be sufficient for majority of users. I believe google uses this mechanism to share private calendars or something.

This sounds like a good candidate for a plugin to me.

[nkantrowitz]

It is also worth noting that the HttpAuth plugin can fix this is you also use AccountManager?.

[object01@…]

Replying to jan.vornberger@informatik.uni-oldenburg.de:

Another workaround: I use the standalone trac server and since basically everything is password protected for our project, I simply patched the authentication code in such a way, that it _always_ asks for a password. Simple hack, that I just wanted to share it, in case it might be a possible workaround for others. Replace this line (line 47) in .../python2.4/site-packages/trac/web/standalone.py {{{ if len(path_parts) > self.part and path_parts[self.part] == 'login': }}} with this one {{{ if len(path_parts) > 0: }}} Regards, Jan

When I tried this, I found that tracd would randomly (more often than not) reset connections on POST requests. So I augmented your hack with,

if len(path_parts) > 0 and environ.get('REQUEST_METHOD', ) != 'POST':

[frank@…]

Has any progress been made on this point?

Is there a login functionality available that redirects to a separate folder / file with that functionality - like mentioned around 2004?

Or is it really postponed to 2.0 -- which seems very far in the future? Just wondering ...

[Daniel Kahn Gillmor <dkg-debian.org@…>]

nik4536's HttpLoginViaRedirectPatch seems to me to resolve this issue, at least for systems using any standard form of authentication. Given that the patch is relatively small, doesn't break the existing URL space, adds important functionality to trac, and doesn't seem (to me, anyway) to raise any additional security risks, is there any reason that it hasn't been merged upstream yet?

If people see security concerns or think it needs to be re-written, please raise those issues here.

Otherwise, i'd like to strongly advocate for its inclusion upstream. It seems like a good idea and a clean implementation.

[dkhizh@…]

Like coderanger mentioned in http://trac.edgewall.org/ticket/540#comment:42 I used TracHTTPAuth (1.1) http://trac-hacks.org/wiki/HttpAuthPlugin to enable RSS feed while keeping the AccountManager form based login. I have also integrated TracAuthRequired? (0.3.1) into the TracHTTPAuth enabling auto-redirect.

By default, login form used to login. The entire trac is protected by the login form and any unauthenticated requests are redirected to the login form. However, request for RSS feed or Blog are authenticated via HTTPAuth, thus RSS readers can get to them.

[root@palomar 0.10]# diff httpauth/filter.py filter.py_orig 18c18,19 < paths = ListOption?('httpauth', 'paths', default='/blog', doc='Paths to force HTTP authentication on.') ---

paths = ListOption?('httpauth', 'paths', default='/login/xmlrpc', doc='Paths to force HTTP authentication on.')

20,22c21 < formats = ListOption?('httpauth', 'formats', default='rss', doc='Request formats to force HTTP authentication on') < < noredirectpaths = ListOption?('httpauth', 'noredirectpaths', default='/login, /reset_password, /register, /chrome', doc='Paths excluded from redirection to login') ---

formats = ListOption?('httpauth', 'formats', doc='Request formats to force HTTP authentication on')

28,32d26 < # proceed if user is already authenticated < if (req.authname and req.authname != 'anonymous'): < return handler < < # test if HTTP Authentication is applicable 40,57c34,37 < if check: < if not self._check_password(req): < self.log.info('HTTPAuthFilter: No/bad authentication data given, returing 403') < return self < else: < return handle < else: < # check if paths are excluded from login, or redirect to login page < for path in self.noredirectpaths: < if req.path_info.startswith(path): < check = True < break < if check: < return handler < else: < self.log.debug('Redirecting anonymous request to /login') < req.redirect(req.href.login() + '?referer=' + req.abs_href(req.path_info)) < return [] ---

if check and not self._check_password(req): self.log.info('HTTPAuthFilter: No/bad authentication data given, returing 403') return self return handler

I've tested the change on Trac 0.10.4, with TracAccountManager? 0.1.3dev-r2548, and InitAdmin? 0.1.

[dkhizh@…]

Modified TracHTTPAuth 1.1 filter.py file

[anonymous]

4 YEARS OLD NOW? Come on guys, get this issue fixed!

[nkantrowitz]

Replying to anonymous:

4 YEARS OLD NOW? Come on guys, get this issue fixed!

Do not change the severity unless you can show a reason for it. To date the only patch offered has been a copy of my httpauth plugin (which does solve this issue as well as can be expected).

[Remy Blank <remy.blank@…>]

Patch against 0.11-stable adding redirection of URLs below /login

[Remy Blank <remy.blank@…>]

The patch above implements the suggestion from comment:18, which was implemented in th:HttpLoginViaRedirectPatch for 0.9.6:

• All URLs below /login are redirected after authentication to the URL constructed by removing /login:

http://my.trac/login/ticket/3?format=rss
is redirected to
http://my.trac/ticket/3?format=rss

• Accesses to /login (with no sub-path) are redirected to the referrer, as before.

The remaining question is how to make this functionality available to users in an intuitive manner. Indeed, no links in Trac point below /login, and therefore it must be added manually in a copy/paste operation. Not what you would call "user friendly".

So while this patch basically solves the problem for geeks, maybe #5340 is a better solution.

[osimons]

Replying to Remy Blank <remy.blank@…>:

The patch above implements the suggestion from comment:18, which was implemented in th:HttpLoginViaRedirectPatch for 0.9.6:

Note that Trac only responding to ^/login$ is a 'feature' as some plugins use the extended path to make sure that the web server challenges for user/pwd during request handling. Most notably the XMLRPC plugin answers to both /xmlrpc and /login/xmlrpc for those instances where a user context must be ensured. I don't have a full overview of the usage in plugins, or how gracefully they would handle a redirect instead.

The same explicit handling could of course be done in the Trac modules that handle RSS as suggested in previous comments - if a user is authenticated we generate /login/timeline?format=rss alternative link instead, and have the timeline module answer also to such requests. Same with various ticket feeds.

[Remy Blank <remy.blank@…>]

Replying to osimons:

Most notably the XMLRPC plugin answers to both /xmlrpc and /login/xmlrpc for those instances where a user context must be ensured.

Yes, I was aware of that. I had hoped that this change would avoid having to re-code that in every request handler. But what you are saying is that e.g. XML-RPC clients might fail if they receive a redirect instead of data? I hadn't thought of that, and yes, this makes the whole approach moot.

The same explicit handling could of course be done in the Trac modules that handle RSS as suggested in previous comments

This sounds like a good idea. It would not solve the problem for RSS feeds when using th:AccountManagerPlugin and form-based authentication, but this was not the OP's issue.

Would you like me to code this in the various modules providing machine-readable content (RSS, iCalendar)?

[osimons]

Replying to Remy Blank <remy.blank@…>:

But what you are saying is that e.g. XML-RPC clients might fail if they receive a redirect instead of data? I hadn't thought of that, and yes, this makes the whole approach moot.

They may or may not. Most libraries do usually handle a redirect, but some may not. I have no good data on how (or not, or how well) the various 'machine readers' (feeders, programming libraries etc.) handle such things gracefully.

This sounds like a good idea. It would not solve the problem for RSS feeds when using th:AccountManagerPlugin and form-based authentication, but this was not the OP's issue.

AFAIK there is some sort of 'connector' that can also handle HTTP Auth, and by collecting the URLs for all such enforcing logic would perhaps make it even cleaner to detect the circumstances and do configuration? (I don't use it, and have no clue about internals...)

Would you like me to code this in the various modules providing machine-readable content (RSS, iCalendar)?

Sure, your patches are most welcome :-)

[Remy Blank <remy.blank@…>]

Replying to osimons:

I have no good data on how (or not, or how well) the various 'machine readers' (feeders, programming libraries etc.) handle such things gracefully.

At any rate, avoiding redirects can only make it better.

AFAIK there is some sort of 'connector' that can also handle HTTP Auth, and by collecting the URLs for all such enforcing logic would perhaps make it even cleaner to detect the circumstances and do configuration? (I don't use it, and have no clue about internals...)

Err, I don't follow you there... Do you mean th:HttpAuthPlugin? I haven't tried it yet. Looking at the source, I wonder if it supports digest authentication. I'll give it a whirl.

[Remy Blank <remy.blank@…>]

Replying to osimons:

The same explicit handling could of course be done in the Trac modules that handle RSS as suggested in previous comments - if a user is authenticated we generate /login/timeline?format=rss alternative link instead, and have the timeline module answer also to such requests. Same with various ticket feeds.

I tried it, but this has a serious drawback. While I can make the alternative format link at the bottom of e.g. the timeline point below /login, and have the timeline module answer the request, all links in the returned resource (e.g. RSS feed) still point to the normal pages (i.e. without /login). So the feedreader will be able to retrieve the feed, but not the associated items.

But here's another idea: instead of redirecting from URLs below /login, why not "mirror" the whole application below /login without redirecting? This means that all links on pages below /login would also point there. The patch that follows does exactly that.

[Remy Blank <remy.blank@…>]

Patch against 0.11-stable mirroring the whole application below /login

[Remy Blank <remy.blank@…>]

A few comments:

• The "mirroring" is done by changing the environment variables that define req.path_info and req.base_path if req.path_info starts with /login/.
• An additional Href object is created as req.auth_href with SCRIPT_NAME + /login as a base. It should be used to create "always authenticated" links while avoiding generating e.g. /login/login/timeline?format=rss from /login/timeline.
• There is an example of generating an "always authenticated" link in the timeline for authenticated users only. Maybe this should be made configurable through an option in trac.ini.

What do you think? Would this be an acceptable solution? If yes, I can add similar changes to the other modules.

[Remy Blank <remy.blank@…>]

The second attachment in #5340 adds a redirection to /login and back for unauthenticated requests to pages requiring authentication. With this, I have been able to get Thunderbird and Akregator to fetch and display the timeline RSS feed correctly, when the timeline module is restricted to authenticated users.

It seems that both feed readers are able to cope with redirections and authentication cookies. You have to help Thunderbird a bit by setting the following option in user.js (see http://kb.mozillazine.org/RSS_cookies_(Thunderbird)):

user_pref("network.cookie.cookieBehavior", 3);

This looks like the ideal solution except in the following cases:

• When e.g. the timeline is not restricted, but its items are. Then the RSS feed will be retrieved without authentication, and will just contain unrestricted items. This could be solved by adding a parameter that provokes authentication to resources like the timeline that filter what they display based on the authentication level.

• When using form-based login with th:AccountManagerPlugin.

[Daniel Kahn Gillmor <dkg-debian.org@…>]

Replying to Remy Blank <remy.blank@…>:

* When e.g. the timeline is not restricted, but its items are. Then the RSS feed will be retrieved without authentication, and will just contain unrestricted items. This could be solved by adding a parameter that provokes authentication to resources like the timeline that filter what they display based on the authentication level.

This scenario is a serious concern to me. If we're adding a parameter that always forces a login for unauthenticated users, that's basically equivalent to reserving the URL space under /login for the same purpose (unless the URL space under /login is really already actively used in the wild). The advantage of reserving the URL space under /login instead of doing redirection with auth cookies, etc, is that users don't need to worry about fiddling with RSS feed reader cookies and redirections, etc. If they successfully log in with HTTP auth for the page, they get the data that they requested directly.