Edgewall Software
Modify

Opened 10 years ago

Closed 4 years ago

Last modified 19 months ago

#540 closed defect (fixed)

Permissions and RSS Feeds

Reported by: anonymous Owned by: rblank
Priority: high Milestone: 1.0
Component: admin/web Version: 0.7.1
Severity: normal Keywords: RSS permission tickets reports patch
Cc: evan@…, mbertier@…, melo-trac-tickets@…, dserodio@…, hleroux@…, kyle@…, core@…, jorge.vargas@…, rupert.thurner@…, ahsamuel@…, jeff@…, steinsiv@…, frank@…, dkg-debian.org@…, danlipsitt@…, dkhizh@…, captain.mubbers@…, leho@…, osimons
Release Notes:

Redirect RSS and ICS links through /login for authenticated users, so that readers login when requesting the feeds.

API Changes:

Description

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.

Attachments (8)

filter.py (3.4 KB) - added by dkhizh@… 7 years ago.
Modified TracHTTPAuth 1.1 filter.py file
540-login-redirect-r7414.patch (1.4 KB) - added by Remy Blank <remy.blank@…> 6 years ago.
Patch against 0.11-stable adding redirection of URLs below /login
540-login-mirror-r7423.patch (1.5 KB) - added by Remy Blank <remy.blank@…> 6 years ago.
Patch against 0.11-stable mirroring the whole application below /login
540-altlink-rewrite-r10175.patch (3.4 KB) - added by rblank 4 years ago.
Rewrite selected alternative format links to redirect through /login.
t540-timeline_rss_login-r10174.diff (1.1 KB) - added by osimons 4 years ago.
Fix for Timeline RSS for authenticated users (force login).
540-auth-altlinks-r10178.patch (4.5 KB) - added by rblank 4 years ago.
One more try, in core this time.
540-auth-altlinks-r10300.patch (7.9 KB) - added by rblank 4 years ago.
Factored out auth link creation.
540-auth-altlinks-r10316.patch (10.4 KB) - added by rblank 4 years ago.
Don't create a new trac_auth cookie for every call to /login.

Download all attachments as: .zip

Change History (113)

comment:1 Changed 10 years ago by 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.

comment:2 Changed 10 years ago by daniel

  • Milestone set to 0.8
  • Priority changed from normal to high

comment:3 Changed 10 years ago by anonymous

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

comment:4 Changed 10 years ago by cmlenz

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

comment:5 Changed 10 years ago by daniel

  • Owner changed from jonas to daniel
  • Status changed from new to assigned

comment:6 Changed 10 years ago by daniel

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

comment:7 Changed 10 years ago by anonymous

  • Milestone changed from 0.8 to 1.0

comment:8 Changed 10 years ago by daniel

  • Milestone changed from 1.0 to 2.0

comment:9 Changed 10 years ago by 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

comment:10 Changed 10 years ago by 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?

comment:11 Changed 10 years ago by 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.

comment:12 Changed 10 years ago by mgood

#1405 has been marked as a duplicate of this ticket

comment:13 Changed 10 years ago by 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.

comment:14 Changed 9 years ago by 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.

comment:15 Changed 9 years ago by anonymous

  • Cc evan@… added

comment:16 Changed 9 years ago by anonymous

  • Resolution set to wontfix
  • Status changed from assigned to closed

comment:17 Changed 9 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

comment:18 Changed 9 years ago by 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.

comment:19 Changed 9 years ago by Alexander Shopov <ash@…>

  • Cc ash@… added

#1767 is a duplicate of this issue.

comment:20 Changed 9 years ago by cmlenz

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

comment:21 Changed 9 years ago by cmlenz

#1951 has been marked as duplicate of this ticket.

comment:22 Changed 9 years ago by anonymous

  • Cc mbertier@… added

comment:23 Changed 9 years ago by Pedro Melo <melo-trac-tickets@…>

  • Cc melo-trac-tickets@… added

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,

comment:24 Changed 9 years ago by 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.

comment:25 Changed 9 years ago by 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.

comment:26 Changed 9 years ago by 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.

comment:27 Changed 9 years ago by 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?

comment:28 Changed 9 years ago by dserodio@…

  • Cc dserodio@… added

comment:29 Changed 9 years ago by Hervé Leroux

  • Cc hleroux@… added

Seems to work rocha Thanks Rv

comment:30 Changed 9 years ago by cmlenz

#2607 has been marked as dupe of this ticket.

comment:31 Changed 9 years ago by anonymous

  • Cc kyle@… added

comment:32 Changed 9 years ago by 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?

comment:33 Changed 9 years ago by core@…

  • Cc core@… added

comment:34 follow-up: Changed 9 years ago by anonymous

  • Cc ben@… added

comment:35 in reply to: ↑ 34 Changed 8 years ago by anonymous

  • Keywords permission added

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.

comment:36 Changed 8 years ago by 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

comment:37 Changed 8 years ago by 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

comment:38 Changed 8 years ago by Jorge <jorge.vargas@…>

  • Cc jorge.vargas@… added

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?

comment:39 follow-up: Changed 8 years ago by 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

comment:40 follow-up: Changed 8 years ago by 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.

comment:41 in reply to: ↑ 40 Changed 8 years ago by 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.

comment:42 Changed 8 years ago by nkantrowitz

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

comment:43 Changed 8 years ago by anonymous

  • Cc rupert.thurner@… added

comment:44 Changed 7 years ago by anonymous

  • Cc ahsamuel@… added

comment:45 Changed 7 years ago by anonymous

  • Cc remy.blank@… added

comment:46 Changed 7 years ago by anonymous

  • Cc andy@… added

comment:47 Changed 7 years ago by jeff@…

  • Cc jeff@… added

comment:48 in reply to: ↑ 39 Changed 7 years ago by 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':

comment:49 Changed 7 years ago by steinsiv

  • Cc steinsiv@… added

comment:50 Changed 7 years ago by frank@…

  • Cc frank@… added

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 …

comment:51 Changed 7 years ago by Daniel Kahn Gillmor <dkg-debian.org@…>

  • Cc dkg-debian.org@… added

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.

comment:52 Changed 7 years ago by Dan Lipsitt <danlipsitt@…>

  • Cc danlipsitt@… added

comment:53 Changed 7 years ago by 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.

Changed 7 years ago by dkhizh@…

Modified TracHTTPAuth 1.1 filter.py file

comment:54 Changed 7 years ago by dkhizh@…

  • Cc dkhizh@… added

comment:55 follow-up: Changed 6 years ago by anonymous

  • Severity changed from normal to major

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

comment:56 in reply to: ↑ 55 Changed 6 years ago by nkantrowitz

  • Severity changed from major to normal

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

Changed 6 years ago by Remy Blank <remy.blank@…>

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

comment:57 follow-up: Changed 6 years ago by Remy Blank <remy.blank@…>

  • Cc remy.blank@… removed
  • Keywords patch added

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.

comment:58 Changed 6 years ago by Remy Blank <remy.blank@…>

  • Cc remy.blank@… added

comment:59 in reply to: ↑ 57 ; follow-ups: Changed 6 years ago by 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.

comment:60 in reply to: ↑ 59 ; follow-up: Changed 6 years ago by 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)?

comment:61 in reply to: ↑ 60 ; follow-up: Changed 6 years ago by osimons

  • Milestone changed from 2.0 to 0.13

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 :-)

comment:62 in reply to: ↑ 61 Changed 6 years ago by 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.

comment:63 in reply to: ↑ 59 Changed 6 years ago by 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.

Changed 6 years ago by Remy Blank <remy.blank@…>

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

comment:64 Changed 6 years ago by 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.

comment:65 follow-up: Changed 6 years ago by 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.

comment:66 in reply to: ↑ 65 Changed 6 years ago by 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.

comment:67 Changed 6 years ago by anonymous

  • Owner changed from daniel to anonymous
  • Status changed from reopened to new

comment:68 Changed 6 years ago by anonymous

  • Resolution set to fixed
  • Status changed from new to closed

comment:69 Changed 6 years ago by rblank

  • Resolution fixed deleted
  • Status changed from closed to reopened

Please stop that.

comment:70 Changed 6 years ago by starman

  • Component changed from general to admin/web

comment:71 Changed 6 years ago by rblank

  • Cc remy.blank@… removed

comment:72 Changed 6 years ago by 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"

comment:72 Changed 6 years ago by 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"

comment:73 Changed 6 years ago by anonymous

  • Cc ash@… removed

comment:74 in reply to: ↑ description Changed 5 years ago by 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.

comment:75 Changed 5 years ago by captain.mubbers@…

  • Cc captain.mubbers@… added

comment:76 Changed 5 years ago by chris@…

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

Plugins:

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.

comment:77 Changed 5 years ago by konstantin

It's httpauth, not httpdauth

comment:78 Changed 5 years ago by Andy <andy@…>

  • Cc andy@… removed

comment:79 Changed 5 years ago by lkraav <leho@…>

  • Cc leho@… added

comment:80 follow-up: Changed 5 years ago by 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

comment:81 Changed 5 years ago by Benjamin Zeiss <ben@…>

  • Cc ben@… removed

comment:82 in reply to: ↑ 80 Changed 5 years ago by rblank

  • Owner changed from anonymous to rblank
  • Status changed from reopened to new

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

comment:83 Changed 4 years ago by rblank

#9326 was closed as a duplicate.

comment:84 Changed 4 years ago by 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.

comment:85 Changed 4 years ago by 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?

comment:86 Changed 4 years ago by 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!!

Changed 4 years ago by rblank

Rewrite selected alternative format links to redirect through /login.

comment:87 follow-up: Changed 4 years ago by rblank

  • Milestone changed from next-major-0.1X to 0.13

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?

comment:88 in reply to: ↑ 87 ; follow-up: Changed 4 years ago by 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?

comment:89 in reply to: ↑ 88 ; follow-up: Changed 4 years ago by 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…

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.

comment:90 in reply to: ↑ 89 Changed 4 years ago by cboos

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?

Changed 4 years ago by osimons

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

comment:91 Changed 4 years ago by osimons

  • Cc osimons added

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!

Changed 4 years ago by rblank

One more try, in core this time.

comment:92 Changed 4 years ago by rblank

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.

comment:93 follow-up: Changed 4 years ago by rblank

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.

comment:94 Changed 4 years ago by cboos

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

comment:95 in reply to: ↑ 93 Changed 4 years ago by 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.

comment:96 Changed 4 years ago by rblank

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

Changed 4 years ago by rblank

Factored out auth link creation.

comment:97 Changed 4 years ago by rblank

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.

Changed 4 years ago by rblank

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

comment:98 Changed 4 years ago by rblank

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?

comment:99 Changed 4 years ago by rblank

  • Release Notes modified (diff)
  • Resolution set to fixed
  • Status changed from new to closed

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

comment:100 Changed 19 months ago by 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.

comment:101 Changed 19 months ago by 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

comment:102 Changed 19 months ago by cboos

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.

comment:103 Changed 19 months ago by 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.

comment:104 Changed 19 months ago by cboos

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 ;-)

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed The owner will remain rblank.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from rblank to the specified user.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.