Opened 13 years ago

Closed 12 years ago

Last modified 9 years ago

#6254 closed defect (fixed)

Cookie auth method does not work to get images on servers using HTTP auth

Reported by: Jason Winnebeck Owned by: Álvaro Iradier
Priority: normal Component: TracWikiPrintPlugin
Severity: normal Keywords:
Cc: Trac Release: 0.11


If the server uses HTTP auth instead of the "login" link, then the plugin is unable to get images.

2009-11-24 12:06:12,570 Trac[wikiprint] DEBUG: Adding cookie to HTTP request: pdfgenerator_cookie=2ebee5dad6f07ae6143baba98a875853
2009-11-24 12:06:12,617 Trac[wikiprint] DEBUG: WikiPrint.linkLoader ERROR: HTTP Error 401: Authorization Required

Is there a way to pass through the HTTP credentials from the incoming request? I fear that it is not possible. I was hoping that this PDF generator tool would work on our server, since no other known solution works (since the server is both HTTPS and requires HTTP auth to every page).

Attachments (0)

Change History (13)

comment:1 Changed 12 years ago by anonymous

Owner: changed from Álvaro Iradier to anonymous
Status: newassigned

comment:2 Changed 12 years ago by anonymous

Owner: changed from anonymous to Álvaro Iradier
Status: assignednew

comment:3 Changed 12 years ago by Álvaro Iradier

Status: newassigned

comment:4 Changed 12 years ago by Álvaro Iradier

Related to #5722

comment:5 Changed 12 years ago by Jason Winnebeck

Do you have a plan in mind to address this?

I don't know if I thought if it before but something just popped up into my head. The cookie-based auth is nice because it allows the plugin to follow properly the Trac authorizations, unlike other plugins. So in a way it would not be inappropriate to partially "defeat" the HTTP auth. What if the plugin could be configured with a fixed (for all requests from the site) HTTP(S) username and password? I as an admin would create an account specifically for the plugin that is used only in its configuration locally on the server and normally doesn't have any privileges itself. Then that would allow the processing to "break through" the HTTP auth enough to pass the cookie, at which point the plugin implements the full and proper security checks.

comment:6 Changed 12 years ago by Álvaro Iradier

I think we can get the username and password from the HTTP request, so my idea was simply to make Wikiprint use the same username and password from the request. I have to take a look at it.

comment:7 Changed 12 years ago by Jason Winnebeck

That would be ideal if you can do that. That would replace the cookie-based version. However, I would be surprised if Apache passes on the plaintext password to python/php/cgi/etc. scripts, especially if you consider the possibility of digest HTTP auth or even SSL client certificates. But if you can proxy the credentials somehow, it would be very ideal.

comment:8 Changed 12 years ago by Álvaro Iradier

You're right. It's possible to get the username (or the certificate public information), but not the password.

comment:9 Changed 12 years ago by Jason Winnebeck

I think it makes sense when I think about things like SSL client certs where there is no password at all to give, even if it wanted to.

If I recall the WikiPrint that you use is an external process that tries to hit URLs, so I can't think of a way to proxy the credentials there unless you went as far to actually open a port for it to connect to and proxy WikiPrint connections to Trac resources (which you can access via the plugin code), but that sounds far from practical if not a potential security issue.

comment:10 Changed 12 years ago by Álvaro Iradier

Resolution: fixed
Status: assignedclosed

Fixed in r7700

comment:11 Changed 12 years ago by Jason Winnebeck

Thanks for implementing this! I have created an HTTP user 'trac-wikiprint' with a password to be used only for this plugin. This user can now get to the (authorized users only) Apache server and get to Trac URLs, although this user has no privileges to anything in Trac.

Is the intention that the plugin will use cookies to make Trac act as if it is running the permissions of the user making the book? I see the cookie getting sent:

2010-02-23 09:11:54,398 Trac[wikiprint] DEBUG: Adding cookie to HTTP request: pdfgenerator_cookie=XXXXX
2010-02-23 09:11:54,491 Trac[main] DEBUG: Dispatching <Request "GET u'/raw-attachment/wiki/Tutorials/USBDatabaseBackup/SyncDiagram.png'">
2010-02-23 09:11:54,510 Trac[perm] DEBUG: LegacyAttachmentPolicy denies trac-wikiprint performing ATTACHMENT_VIEW on <Resource u'wiki:Tutorials/USBDatabaseBackup, attachment:SyncDiagram.png'>
2010-02-23 09:11:54,511 Trac[main] WARNING: HTTPForbidden: 403 Forbidden (ATTACHMENT_VIEW privileges are required to perform this operation on Attachment 'SyncDiagram.png' in Tutorials/USBDatabaseBackup)

It looks like Trac is trying to validate permissions to the trac-wikiprint user and not my own (that of the requestor).

I could probably give the trac-wikiprint user ATTACHMENT_VIEW if this is what is required. However, wouldn't that allow any user who can edit wiki pages the ability to view and download attachments for any pages? Fortunately in my environment that would be OK -- users who can view wiki in a Trac can view all wiki/attachment content. But I am thinking about possibly other users using the plugins where they can get "private" wiki pages.

When I give the trac-wikiprint user the WIKI_VIEW priviledge, then the plugin does work. Seems that despite the Trac message, I can't add just "ATTACHMENT_VIEW" to a user with trac-admin or web interface.

What do you think? Like I said, myself personally am not too bothered by this but wonder if this is the way you meant it.

comment:12 Changed 12 years ago by Álvaro Iradier

The auth cookie is the one from the requestor. So, if Trac is using Cookie based authentication, wikiprint will authenticate as the requestor user.

However, if you're using HTTP authentication, I think the auth cookie will be ignored, and the HTTP login user will be used instead, so you'll need to give your trac-wikiprint user the required permissions.

About the permissions, I guess you'll have to give the trac-wikiprint all required view permissions (WIKI_VIEW, and probably ATTACHMENT_VIEW?). This could mean that a user could setup a wiki page pointing to a forbidden resource, and run wikiprint PDF export to retrieve it... Yes, probably, but I can't think of an easy way of fixing this.

comment:13 Changed 12 years ago by Jason Winnebeck

OK, well that's fine for me because I'm not using any plugins to make it so that certain pages are forbidden. A user can either view wiki or not, so for me the plugin does not expose anything more.

Might want to document it on the plugin's wiki on what permissions to give. Like I said in my comment trac-admin doesn't know about ATTACHMENT_VIEW despite the debug print, but WIKI_VIEW works. But the debug comes from "LegacyAttachmentPolicy" -- maybe I'm using some older permissions model?

Good work on the plugin, by the way...

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Álvaro Iradier.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment

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

Note: See TracTickets for help on using tickets.