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.

[Christopher Lenz]

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?

[Christopher Lenz]

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?

[Matthew Good]

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.

[Matthew Good]

#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.

[Matthew Good]

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.

[Christopher Lenz]

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

[Christopher Lenz]

#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

[Christopher Lenz]

#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.

[Noah Kantrowitz]

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.

[Noah Kantrowitz]

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!

[Noah Kantrowitz]

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.

[anonymous]

How is this taking 5 years to fix? It seems like a GAPING feature gap: "RSS only works if you allow the whole world access"

[anonymous]

Replying to 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.

[chris@…]

I have this working on Trac 0.11.4 running as stand-alone tracd with the following setup:

Plugins:

• ​AccountManagerplugin
• ​HttpAuthPlugin

Trac uses form-based authentication with a HtDigest password storage for normal pages. In trac.ini I have

[httpdauth]
formats = rss

Now when I access e.g. /timeline?format=rss, HTTP authentication is requested. Sane feedreaders will then pop up a login dialog.

One Caveat: if I enable the WorkflowEditor plugin I get an exception due to an empty locale when I access a feed with a simple web client (e.g. Python's urllib). I don't need this plug-in currently, so i just disabled it and everything works as it should.

[konstantin]

It's httpauth, not httpdauth

[torpe23@…]

Using a sort of workaround, I'm able to read the authenticated rss feed from any rss reader: check on blog.porquet.org/post/2009/01/20/Akregator-and-Trac-authenticated-rss-feed

[Remy Blank]

Replying to torpe23@…:

Using a sort of workaround, I'm able to read the authenticated rss feed from any rss reader: check on blog.porquet.org/post/2009/01/20/Akregator-and-Trac-authenticated-rss-feed

This is a very creative use of the referer= argument to /login, for sure. I have yet to test it, but if it works, we could actually generate RSS feed links of this type for authenticated users, therefore solving the issue (at least for HTTP authentication; sites using form-based authentication would probably still need the ​th:HttpAuthPlugin).

[Remy Blank]

#9326 was closed as a duplicate.

[gokce.aydos@…]

As a workaround I use query-string based access control, although is not very secure.

RewriteEngine On
RewriteCond %{QUERY_STRING} format=rss
RewriteRule "" - [E=RSS_REQUESTED:1]
<Directory "/var/trac/apache/cgi-bin/">
    SetHandler wsgi-script
    Options +ExecCGI

    AuthType Basic
    AuthName "Restricted Area"
    AuthUserFile "passfile"
    Require valid-user

    Order Deny,Allow
    Deny from all
    Allow from env=RSS_REQUESTED

    # give access by Allow or Require
    Satisfy Any
    </Directory>

I used this circumvention because Setenvif and many other directives don't have access to the environment variable QUERY_STRING.

[mqmvoip@…]

I have a similar problem. I am using PHP to fetch data from TRAC via RSS. Using the login&password in the URL (​http://user:pwd@myhost.com) does not solve it.

I am trying to fetch the tsv (tab-separated values) version of the report, using PHP´s "file" functionhttp://www.php.net/manual/en/function.file.php . But I ran into the same problem - it only works for TRACs where anonymous have REPORT_VIEW priv. I tried inserting the login&password in the URL here as well, to no avail.

Any ideas on how I can connect to a TRAC´s report which needs a login, and fetch teh TSV report, via PHP? I don´t mind if I have to write 20 lines of code for that, but I have tried many options and nothing. I even tried playing with ​http://www.php.net/manual/en/context.php , to see if I could pass through some authentication, but no success.

Any hope?

[mqmvoip@…]

Even plain old curl from the cmd-line does not seem to work:

curl -v —get —user foo:bar -d asc=1 -d format=tab —url ​http://web/trac/juris/report/26

This also produces an error page, even though the user foo has REPORT_VIEW privileges.

Can anybody at least get curl to fetch a TRAC report, given a username/password? Thanks!!

[Remy Blank]

Rewrite selected alternative format links to redirect through /login.

[Remy Blank]

540-altlink-rewrite-r10175.patch​ is another stab at this issue, based on comment:82. It defines an optional component tracopt.web.altlinks.AltLinkLoginRewriter that rewrites selected alternative format links (e.g. RSS feed links) so that they redirect through /login with a referer= query argument, and hence require authentication. This ensures RSS readers log in before requesting the feed.

Of course, form-based login won't work with this scheme and will still require using the ​th:HttpAuthPlugin.

Thoughts?

[osimons]

Replying to rblank:

540-altlink-rewrite-r10175.patch​ is another stab at this issue, based on comment:82.

It has a somewhat more hack-ish feel than most other Trac code… :-) Why don't you put it up on ​http://track-hacks.org along with the other alternatives, and if it proves its worth then we can add it back to tracopt.* namespace later?

[Remy Blank]

Replying to osimons:

It has a somewhat more hack-ish feel than most other Trac code… :-)

No, it's a middle approach between code in core with a configuration option to enable or disable it, and code outside of core. It is supposed to make both camps (plugin vs. core) at least somewhat happy, but it may just make both camps unhappy…

Why don't you put it up on ​http://track-hacks.org along with the other alternatives, and if it proves its worth then we can add it back to tracopt.* namespace later?

For several reasons:

• It is currently not possible to read e.g. the timeline RSS feed in an external reader (i.e. not a browser) if a site has some public parts but the feed isn't public. This is a defect, not an enhancement request.
• Judging from the number of people in CC and the number of comments on this ticket, there is a strong need for fixing this issue. I have this need myself, and have worked around it by quoting and expanding the RSS URL in my feed reader by hand.
• I don't believe in "Trac hacks first, core if it's popular", because this just never happens (the only exception being WebAdmin, in 7 years of Trac history). I'd rather people would say "not in core", because it's really equivalent.

Personally, I would just fix Trac core to always route RSS and ICS downloads through /login, but the response to my two previous attempts have been shot down / largely ignored, so here's an attempt at a middle ground.

[Christian Boos]

Replying to rblank:

Replying to osimons:

It has a somewhat more hack-ish feel than most other Trac code… :-)

No, it's a middle approach between code in core with a configuration option to enable or disable it, and code outside of core. It is supposed to make both camps (plugin vs. core) at least somewhat happy, but it may just make both camps unhappy…

So I must be located at the other end of the spectrum ;-)

I'd prefer a solution via core rather than tracopt, because this really looks like a defect and it seems we can fix it. Also, I'm afraid that it won't be obvious to "discover" the feature and find out that you have an optional component just for fixing this (let alone a plugin on ​TH).

• I don't believe in "Trac hacks first, core if it's popular", because this just never happens (the only exception being WebAdmin, in 7 years of Trac history).

… and WebAdmin started as an "Edgewall" plugin ;-)

Personally, I would just fix Trac core to always route RSS and ICS downloads through /login, but the response to my two previous attempts have been shot down / largely ignored, so here's an attempt at a middle ground.

Shot down, I don't think so. Ignored, yes… Sorry, at least I didn't have any need for this one until recently. But your original approach looks fine to me. IIUC, the "in-core" approach would be a mix of 540-login-mirror-r7423.patch​ (adding auth_href based links for RSS feeds, but no "mirroring") and 540-login-redirect-r7414.patch​?

[osimons]

Fix for Timeline RSS for authenticated users (force login).

[osimons]

attachment:t540-timeline_rss_login-r10174.diff​ is a patch for my suggestion in comment:59 two years ago. The patch is just for the Timeline RSS - the various other downloads will be added if it works OK and the implementation is agreeable.

It fixes things in Trac core, and fixes it in actual module that produces a link that requires this behaviour.

PS! Remy, I have not managed to keep an eye on this ticket recently. Sorry!

[Remy Blank]

One more try, in core this time.

[Remy Blank]

I must have misread the comments two years ago, because we all seem to agree this should be fixed in core. 540-auth-altlinks-r10178.patch​ implements the login-redirect method in core, for all RSS and ICS format downloads.

Compared to Simon's solution in comment:91, it has the following advantages:

• Per-subsystem changes are minimal and limited to the location where the alternate link is defined. They could even be reduced to a single line, by defining:

  def auth_link(req, href):
      if req.authname != 'anonymous':
          return req.href.login(referer=href)
      return href
  

• Resources (in a broad sense) have a single location, instead of being duplicated below /login. I remember a discussion two years ago on trac-dev (I can't find it ATM, maybe it was in the context of a different issue) where I was told that serving the same resource at two different locations was frowned upon, and that that's what redirects were for.

And, of course, the following drawback:

• It uses a redirect from /login back to the original location after authentication. While none of the RSS readers I have tested seem to mind, it may still prevent some readers from accessing the feeds.

I haven't tested any of the methods with ​th:AccountManagerPlugin and form-based login, so that's next on my list.

[Remy Blank]

​th:AccountManagerPlugin still suffers from flaky redirect after login, see ​#TH7687. Once this is fixed, the "extended" links through /login work even with form-based login (when following them in the browser), but of course no RSS reader will know how to handle the form.

[Christian Boos]

demo-0.13 is running with 540-auth-altlinks-r10178.patch​, that could facilitate the testing (in order to log in there, first logout of t.e.o).

[hasienda <hoff.st@…>]

(In ​[9263]): ​AccountManagerPlugin: Remove private redirection after login, closes ​#7687.

This might have been a fix for a previously bad or inconsistent behaviour. But meanwhile it changed into a hindrance to make redirection to referer after login work properly in current Trac.

[Remy Blank]

So, any comments on 540-auth-altlinks-r10178.patch​? Ok to apply?

[Remy Blank]

Factored out auth link creation.

[Remy Blank]

540-auth-altlinks-r10300.patch​ is one last stab at this, it factors out the link creation as suggested in comment:92. If nobody objects, I'm going to commit this shortly.

[Remy Blank]

Don't create a new trac_auth cookie for every call to /login.

[Remy Blank]

There is still one issue with redirecting through /login. Every call to /login currently creates a new trac_auth cookie. If an RSS feed reader polls the feed every 10 minutes, the auth_cookie table would very quickly fill up.

540-auth-altlinks-r10316.patch​ avoids this by checking if a cookie has already been set and is valid, and only creating a new cookie if that's not the case.

Thoughts?

[Remy Blank]

Last patch applied in [10345] and [10346].

[anonymous]

So in summary… how would one get this to work in Trac v1.0?
I tried connecting an RSS reader to my project's timeline (which is secure) and it didn't ask for username and password and wouldn't allow me to read the feed.

[anonymous]

In other words I still get the 403 error when connecting to the timeline url such as this:
​http://my.domain.com/trac/myproject/timeline?wiki=on&max=50&daysback=90&format=rss

[Christian Boos]

The point of the change was that once you're logged in, the generated RSS links don't look like .../something?format=rss anymore, but rather like .../login?referer=%2Ftimeline%3Fformat%3Drss, which will force your RSS reader to go through an authentication step before.

[anonymous]

But none of that works. Doesn't matter what URL I put in (I've tried all the suggestions above) I still just get a 403 error. I've taken this up directly with the developers of one RSS reader (NetNewsWire) and they could not get it to work with any trac installation either. It's broken. If you can't connect via CURL then it won't work with an RSS reader either.

If you think you can get it to work with CURL, then please show a full working example on a sample trac installation somewhere because none of the pseudo-code above works.

[Christian Boos]

I just verified once again with current versions (1.0.2dev and 1.1.1dev) and it does work, at least with Thunderbird (17.0.5). So now if you (or someone else) still have issues with this feature, please follow these steps:

• verify that the Trac server you're trying to connect to is recent enough (version ≥ 1.0)
• use the URL provided by the RSS link given in the Alternate formats when you're logged in (i.e. the URL must look like http://trac.edgewall.org/login?referer=%2Fticket%2F540%3Fformat%3Drss)
• check with Thunderbird, it should work
• check with your favorite RSS Reader, if it doesn't work, it's probably an issue with the reader if it worked with Thunderbird
• if you still don't manage to make it work, ask on the MailingList

And if after all this, we figure out there's a real problem worth of a ticket, open a new one with clear reproduction steps. Thanks.

[OT] freeze ticket feature wanted ;-)

[Ryan J Ollos]

If I hover over the timeline RSS link, right click and copy link address, the copied URL is:

/login?referer=%2F<sitename>%2Ftimeline%3Fticket%3Don%26ticket_details%3Don%26max
%3D50%26authors%3D%26daysback%3D90%26format%3Drss

However if I follow the link and copy it from the browser address bar, the URL is

/timeline?ticket=on&ticket_details=on&max=50&authors=&daysback=90&format=rss

Due to the latter behavior I didn't realize until I searched for this ticket that RSS feeds could be retrieved from sites requiring authentication.

Documentation updated in TracRss@29.

[Ryan J Ollos]

It appears that the RSS client must support authentication. Unfortunately ​Feedly does not. However, I noticed that the GitHub news feed provides a URL with a token that allows the feed to be retrieved in Feedly: /rjollos.private.atom?token=<the-token>. Maybe we could implement something like that in Trac? It's a separate feature request from this ticket, and apologies if this was mentioned … I only read about half of the 105 comments in this ticket!