Opened 4 years ago

Closed 4 years ago

Last modified 11 months ago

#6254 closed defect (fixed)

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

Reported by: JasonWinnebeck Owned by: airadier
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 4 years ago by anonymous

  • Owner changed from airadier to anonymous
  • Status changed from new to assigned

comment:2 Changed 4 years ago by anonymous

  • Owner changed from anonymous to airadier
  • Status changed from assigned to new

comment:3 Changed 4 years ago by airadier

  • Status changed from new to assigned

comment:4 Changed 4 years ago by airadier

Related to #5722

comment:5 Changed 4 years ago by JasonWinnebeck

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 4 years ago by airadier

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 4 years ago by JasonWinnebeck

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 4 years ago by airadier

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

comment:9 Changed 4 years ago by JasonWinnebeck

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 4 years ago by airadier

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

Fixed in r7700

comment:11 Changed 4 years ago by JasonWinnebeck

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 4 years ago by airadier

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 4 years ago by JasonWinnebeck

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

Add Comment

Modify Ticket

as closed .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from airadier. Next status will be 'closed'.
The resolution will be deleted. Next status will be 'reopened'.

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

Note: See TracTickets for help on using tickets.