Edgewall Software
Modify

Opened 14 years ago

Last modified 12 years ago

#6800 new defect

A plugin can not extend HTTP headers of the main trac site if it is a private trac.

Reported by: martin@… Owned by:
Priority: normal Milestone: unscheduled
Component: wiki system Version: 0.11b1
Severity: normal Keywords: openid consider
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

I'm trying to make yahoo.com OpenID provider not complain about "fraudulent" sites by implementing OpenID 2.0 XRDS discovery to the th:AuthOpenIdPlugin copy @ http://ideelabor.ee/opensource/log/python-components/authopenidplugin

Discovery requires the 'base URL' of the trac instance (example.com/trac/project1) to have a X-XRDS-Location header pointing to a XML file. I got over the problem of 'tapping' into wiki module by calling irectly the process_request method of WikiModule after I've added the extra header in the tapping request match: http://ideelabor.ee/opensource/changeset/154/python-components/authopenidplugin

A quick test with a public wiki (anonymous has WIKI_VIEW rights) and yahoo.com had success, but trying another project where anonymous users have zero rights, the wiki system raises a permissions error with req.send_error which clears all outgoing headers set before via this hack.

Question: How can I make a plugin emit an extra header on the main page of the trac instance?

Maybe req.send_error should not clear experimental (X-*) headers?

Attachments (0)

Change History (9)

comment:1 by Remy Blank, 14 years ago

Resolution: worksforme
Status: newclosed

To avoid having to "tap" the process_request() method of the wiki module, you could implement the IRequestFilter interface in your plugin, and add headers in post_process_request().

send_error() indeed clears all previously set headers. OTOH, your site should not be displaying an error page at the root, should it? You could use fine-grained permissions as described in TracFineGrainedPermissions to give anonymous WIKI_VIEW permission on the front page only.

comment:2 by osimons, 14 years ago

post_process_request() has the added advantage of being called when preparing errors as well, so if you add your header there (req._outheaders.append(('XStuff', 'x-stuff-value'))) it should be part of all Trac responses.

comment:3 by Remy Blank, 14 years ago

Unfortunately not. Request.send_error() clears self._outheaders before setting its own headers and sending the response. It is called in _dispatch_request(), after calling the various request handlers and hooks in RequestDispatcher.dispatch().

comment:4 by martin@…, 14 years ago

Resolution: worksforme
Status: closedreopened

Giving permissions is not the goal to achieve - the trac instance is supposed to be private, even the front page.

in reply to:  4 ; comment:5 by Remy Blank, 14 years ago

Keywords: consider added
Milestone: 1.0

Replying to martin@…:

Giving permissions is not the goal to achieve - the trac instance is supposed to be private, even the front page.

I was trying to provide an alternative way to solve the issue. If this is not possible for you, then your only option currently is to patch Request.send_error(), either directly in the Trac sources or by monkey-patching it from an IRequestFilter.

I am not sure if adding arbitrary headers to an error page is a good idea, but if you can come up with a clean patch that opens this functionality to plugins, it could be considered.

And no, not clearing X-* headers is not a clean way of implementing this, IMO.

in reply to:  5 ; comment:6 by martin@…, 14 years ago

And no, not clearing X-* headers is not a clean way of implementing this, IMO.

What is the point of clearing all headers in the first place ?

in reply to:  6 comment:7 by Remy Blank, 14 years ago

Replying to martin@…:

What is the point of clearing all headers in the first place ?

I don't know. I was hoping that one of the other developers would chime in. As errors are generated during a request, where headers might have been set for the page initially to be displayed, I suppose it is intended to avoid leaving cruft from an unfinished request in the headers.

comment:8 by Christian Boos, 12 years ago

Milestone: 1.0unscheduled

Milestone 1.0 deleted

comment:9 by Christian Boos, 12 years ago

Milestone: triagingunscheduled
Owner: Christian Boos removed
Status: reopenednew

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.