Opened 8 years ago

Closed 8 years ago

## #5215 closed defect (fixed)

Reported by: Owned by: uray airadier normal TracWikiPrintPlugin normal 0.11

### Description

picture generated by graphviz doesn't show up in PDF file.

BTW, url of such picture is like this: http://xxx/trac/proj/graphviz/19ce314ef4123968c4acf6016de4bee2f0a756d9.dot.png

### comment:1 Changed 8 years ago by airadier

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

Should be fixed with r5700, chan you check please?

### comment:2 Changed 8 years ago by uray

• Resolution fixed deleted
• Status changed from closed to reopened

Thanks for your quick response! graphviz issue is fixed, but statistic images (as attachments) lost in generated PDF.

### comment:3 Changed 8 years ago by uray

sorry, typo: statistic => static

### comment:4 Changed 8 years ago by airadier

Could you please enable logging to a file, and attach me the generated trac.log? Or at least, the wikiprint related lines.

### comment:5 Changed 8 years ago by uray

log file is attached, and following is the wiki page which I'm testing:

Test1

[[Image(tiger.png)]]

{{{
#!graphviz
digraph Test {
Hello -> World
}
}}}


### comment:6 Changed 8 years ago by airadier

Ok, I have no idea what the problem can be. In the log, you can see the following:

2009-05-12 14:45:20,127 Trac[_Sandbox_:wikiprint] DEBUG: WikiPrint.linkLoader => Resolving URL: http://seals.vobile.com/trac/_Sandbox_/raw-attachment/wiki/WikiStart/tiger.png


Can you confirm that if you go to the image URL:

http://seals.vobile.com/trac/_Sandbox_/raw-attachment/wiki/WikiStart/tiger.png

(NOTE: I changed cn to com, or my post was being detected as spam ¿?)

you can see the static image?

Next, same is done for the graphviz image:

2009-05-12 14:45:20,286 Trac[_Sandbox_:wikiprint] DEBUG: WikiPrint.linkLoader => Resolving URL: http://seals.vobile.com/trac/_Sandbox_/graphviz/e92b1efe6ff6f9722b62bad379d6fea4608a4a67.dot.png


Is the image displayed correctly if you choose Printable HTML format?

### comment:7 Changed 8 years ago by uray

URL 'http://seals.vobile.com/trac/_Sandbox_/raw-attachment/wiki/WikiStart/tiger.png' is valid, the browser will pop up a window prompt me to open or download. In "Printable HTML" page, the image and graphviz both displayed correctly.

### comment:8 Changed 8 years ago by airadier

The log, after:

2009-05-12 14:45:20,127 Trac[_Sandbox_:wikiprint] DEBUG: WikiPrint.linkLoader => Resolving URL: http://seals.vobile.com/trac/_Sandbox_/raw-attachment/wiki/WikiStart/tiger.png


2009-05-12 14:45xx,xxx Trac[main] DEBUG: Dispatching <Request "GET u'/raw-attachment/wiki/WikiStart/tiger.png'">
2009-05-12 14:45xx,xxx Trac[chrome] DEBUG: Prepare chrome data for request
2009-05-12 14:45xx,xxx Trac[attachment] DEBUG: Trying to open attachment at /.../_Sandbox_/attachments/wiki/WikiStart/tiger.png


is there something like that, or any error messages?

### comment:9 follow-up: ↓ 10 Changed 8 years ago by uray

Just noticed if I'm not login as some user, when opening URL 'http://seals.vobile.com/trac/_Sandbox_/raw-attachment/wiki/WikiStart/tiger.png', the browser will ask me for login (plugin TracAuthRequired is installed), this will prevent the image to display, does this means anything?

Thanks!

### comment:10 in reply to: ↑ 9 Changed 8 years ago by airadier

Just noticed if I'm not login as some user, when opening URL 'http://seals.vobile.com/trac/_Sandbox_/raw-attachment/wiki/WikiStart/tiger.png', the browser will ask me for login (plugin TracAuthRequired is installed), this will prevent the image to display, does this means anything?

When making the PDF, the plugin will create a temporary cookie and handle it to the linkloader, so the linkloader should, when fetching the image, have the same permissions as the logged user that requested the PDF.

If something is wrong, there should be something in the trac.log. That's what I was trying to see and asked for in the previous message.

I don't know if TracAuthRequired is doing something... where can I find that plugin?

Also, are you using Trac 0.11?

### comment:11 Changed 8 years ago by uray

Full trac log and apache log is attached as wikiprint2.log.tgz

Yes, I am using Trac 0.11, for plugin TracAuthRequired, here is the URL: http://trac-hacks.org/wiki/AuthRequiredPlugin

### comment:12 Changed 8 years ago by uray

I've disabled AuthRequiredPlugin, from trac.log (attached as wikiprint3.log.gz), about line 49 shows something:

LegacyAttachmentPolicy denied anonymous access to <Resource u'wiki:WikiStart, attachment:tiger.png'>. User needs WIKI_VIEW


so, I grant permission WIKI_VIEW to anonymous, then click 'PDF Article', all images displayed correctly!

### comment:13 Changed 8 years ago by airadier

I'm glad you fixed it, but anyways it should work without giving anonymous user WIKI_VIEW permissions.

I was able to reproduce the problem by adding:

wikiprint.wikiprint.wikiprint = disabled


in components section in trac.ini. That disabled the component was making the authentication magic, so the linkloader was trated as anonymous user, and redirected to the login page. Are you sure all components where enabled? It should be:

wikiprint.* = enabled


in the components section. If you want to disable some options, at least make sure wikiprint.wikiprint.wikiprint is enabled.

Could you try this, and reverting WIKI_VIEW permissions to anonymous?

I'm commiting some minor log and comment changes too.

Thanks.

### comment:14 follow-up: ↓ 15 Changed 8 years ago by uray

Yes, all components are enabled, by setting

wikiprint.* = enabled


int trac.ini.

But by granting any permission to anonymous is not acceptable for us, so I am still doing my investigate ...

### comment:15 in reply to: ↑ 14 Changed 8 years ago by airadier

I would suggest adding some additional debug messages in AuthRequiredPlugin and in WikiPrint. Specially, in the IAuthenticator methods in wikiprint.py. The authenticate method in there will check if there's a special authentication cookie:

    def _get_name_for_cookie(self, cookie):

def authenticate(self, req):
authname = None

return authname


Before calling the PDF, wikiprint generates a random value 'XXXXX', stores the user name it in self.cookiesXXXXX?, and passes this random value to the linkloader.

The linkloader, that fetches images from trac via http, will add the Cookie: pdfgenerator_cookie=XXXXX header to the HTTP request. If everything is correct, trac should try calling the authenticate method in wikiprint.py, which will find the pdfgenerator_cookie', and recover the username. I wonder if the authrequire plugin is making the redirection before this happens.

Yes, all components are enabled, by setting

wikiprint.* = enabled


int trac.ini.

But by granting any permission to anonymous is not acceptable for us, so I am still doing my investigate ...

### comment:16 Changed 8 years ago by uray

Thanks! By adding some debug message, found that the method 'authenticate' in wikiprint.py has never been called (AuthRequiredPlugin is already disabled) during PDF generating.

### comment:17 follow-up: ↓ 18 Changed 8 years ago by uray

seems plugin TracAccountManager must be installed, or the method 'authenticate' in wikiprint.py will never been called, if this is true, maybe it should be mentioned in somewhere (I'm not quite familiar with Trac).

next problem: 'authname' returned from '_get_name_for_cookie' is always 'None', here is the value of 'req.incookie':

Set-Cookie: caca=hola


### comment:18 in reply to: ↑ 17 Changed 8 years ago by airadier

seems plugin TracAccountManager must be installed, or the method 'authenticate' in wikiprint.py will never been called, if this is true, maybe it should be mentioned in somewhere (I'm not quite familiar with Trac).

Thanks for your research. I'm using TracAccountManager, so you must be right. I'll take a look and try to make it work without it, as IAuthenticator interface is from Trac, not AccountManager.

next problem: 'authname' returned from '_get_name_for_cookie' is always 'None', here is the value of 'req.incookie':

Set-Cookie: caca=hola


Ok, before going further into this, please update to latest version I commited yesterday. The caca=hola cookie shouldn't be there, it's kind of "foo=hello" test I made and forgot to remove.

### comment:19 Changed 8 years ago by airadier

I tried to replay the problem removing TracAccountManager, and still no luck. Anyways, accountmanager is listed as a dependency for the authrequired plugin.

I've commited some changes and more debug output, could you update and try with the latest version, then send me the full trac.log again?

Thanks.

### comment:20 Changed 8 years ago by uray

Hi, full trac.log is attached as wikiprint4.log.gz. Have good luck!

### comment:21 Changed 8 years ago by airadier

Ok, I get it. In my setup, I'm using mod_python, so the environment is persistent between requests. In your setup, it looks like you're using wsgi, or fastcgi maybe? From the log you can see that trac is being reloaded in the image request, so the relation cookie-user is lost.

Let me take a look how can I fix this. Probably persisting the cookie to the database should work.

### comment:22 Changed 8 years ago by uray

I am also using mod_python, this is my apache configuration: {{ <Location /trac>

SetHandler mod_python PythonHandler trac.web.modpython_frontend PythonInterpreter main_interpreter PythonOption TracEnvParentDir /seals/trac/projects PythonOption TracUriRoot /trac PythonOption PYTHON_EGG_CACHE /seals/trac/.egg-cache

</Location> }} is there anything different with yours?

### comment:23 follow-up: ↓ 24 Changed 8 years ago by uray

I am also using mod_python, this is my apache configuration:

<Location /trac>
SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonInterpreter main_interpreter
PythonOption TracEnvParentDir /seals/trac/projects
PythonOption TracUriRoot /trac
PythonOption PYTHON_EGG_CACHE /seals/trac/.egg-cache
</Location>


is there anything different with yours?

### comment:24 in reply to: ↑ 23 Changed 8 years ago by airadier

Similar, but without PythonInterpreter option. I was able to replay the problem (and a trac.log similar to yours) by setting

MaxRequestsPerChild 1


in apache's httpd.conf. This reloads the python interpreter on every request. I can notice it's reloading because of the entries:

2009-05-13 15:30:37,000 Trac[loader] DEBUG: Loading trac.ticket.web_ui from c:\python25\lib\site-packages\trac-0.11.4-py2.5-win32.egg
...


in trac.log.

I'm trying to fix this anyways.

I am also using mod_python, this is my apache configuration:

<Location /trac>
SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonInterpreter main_interpreter
PythonOption TracEnvParentDir /seals/trac/projects
PythonOption TracUriRoot /trac
PythonOption PYTHON_EGG_CACHE /seals/trac/.egg-cache
</Location>


is there anything different with yours?

### comment:25 Changed 8 years ago by airadier

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

(In [5727]) Persist PDF generation auth cookie in database. Should fix #5215

### comment:26 Changed 8 years ago by uray

Confirmed, both attachment image and graphviz generated image are displayed correctly! Thank you very much!