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

[Jason Winnebeck]

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

[Álvaro Iradier]

Related to #5722

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

[Á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.

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

[Álvaro Iradier]

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

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

[Álvaro Iradier]

Fixed in r7700

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

[Á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.

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