#5215 closed defect (fixed)
about graphviz
Reported by: | uray | Owned by: | Álvaro Iradier |
---|---|---|---|
Priority: | normal | Component: | TracWikiPrintPlugin |
Severity: | normal | Keywords: | |
Cc: | Trac Release: | 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
Attachments (4)
Change History (30)
comment:1 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 Changed 16 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Thanks for your quick response! graphviz issue is fixed, but statistic images (as attachments) lost in generated PDF.
comment:4 Changed 16 years ago by
Could you please enable logging to a file, and attach me the generated trac.log? Or at least, the wikiprint related lines.
Changed 16 years ago by
Attachment: | wikiprint.log.gz added |
---|
comment:5 Changed 16 years ago by
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 16 years ago by
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 2009-05-12 14:45:20,127 Trac[_Sandbox_:wikiprint] DEBUG: WikiPrint.linkLoader => urljoined URL: http://seals.vobile.com/trac/_Sandbox_/raw-attachment/wiki/WikiStart/tiger.png 2009-05-12 14:45:20,128 Trac[_Sandbox_:wikiprint] DEBUG: WikiPrint.linkLoader => path: /trac/_Sandbox_/raw-attachment/wiki/WikiStart/tiger.png 2009-05-12 14:45:20,261 Trac[_Sandbox_:wikiprint] DEBUG: WikiPrint.linkLoader => loading http://seals.vobile.com/trac/_Sandbox_/raw-attachment/wiki/WikiStart/tiger.png to /tmp/pisa-99gYbn.png
That means that the image tiger.png was correctly downloaded to /tmp/pisa-99gYbn.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 2009-05-12 14:45:20,287 Trac[_Sandbox_:wikiprint] DEBUG: WikiPrint.linkLoader => urljoined URL: http://seals.vobile.com/trac/_Sandbox_/graphviz/e92b1efe6ff6f9722b62bad379d6fea4608a4a67.dot.png 2009-05-12 14:45:20,287 Trac[_Sandbox_:wikiprint] DEBUG: WikiPrint.linkLoader => path: /trac/_Sandbox_/graphviz/e92b1efe6ff6f9722b62bad379d6fea4608a4a67.dot.png 2009-05-12 14:45:20,371 Trac[_Sandbox_:wikiprint] DEBUG: WikiPrint.linkLoader => loading http://seals.vobile.com/trac/_Sandbox_/graphviz/e92b1efe6ff6f9722b62bad379d6fea4608a4a67.dot.png to /tmp/pisa-YXDTII.png
So apparently both images are being correctly downloaded...
Is the image displayed correctly if you choose Printable HTML format?
comment:7 Changed 16 years ago by
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 16 years ago by
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:45:20,127 Trac[_Sandbox_:wikiprint] DEBUG: WikiPrint.linkLoader => urljoined URL: http://seals.vobile.com/trac/_Sandbox_/raw-attachment/wiki/WikiStart/tiger.png 2009-05-12 14:45:20,128 Trac[_Sandbox_:wikiprint] DEBUG: WikiPrint.linkLoader => path: /trac/_Sandbox_/raw-attachment/wiki/WikiStart/tiger.png
you should see something like this (and maybe more information):
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 16 years ago by
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 Changed 16 years ago by
Replying to 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?
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?
Changed 16 years ago by
Attachment: | wikiprint2.log.tgz added |
---|
comment:11 Changed 16 years ago by
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
Changed 16 years ago by
Attachment: | wikiprint3.log.gz added |
---|
comment:12 Changed 16 years ago by
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 16 years ago by
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 16 years ago by
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 Changed 16 years ago by
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): if self.cookies.has_key(cookie.value): return self.cookies[cookie.value] def authenticate(self, req): authname = None if req.incookie.has_key('pdfgenerator_cookie'): authname = self._get_name_for_cookie(req.incookie['pdfgenerator_cookie']) 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.
Replying to uray:
Yes, all components are enabled, by setting
wikiprint.* = enabledint trac.ini.
But by granting any permission to anonymous is not acceptable for us, so I am still doing my investigate ...
comment:16 Changed 16 years ago by
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 16 years ago by
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 Set-Cookie: pdfgenerator_cookie=f02f5fdf709ce88a7f31b130029d86e6
comment:18 Changed 16 years ago by
Replying to 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).
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 Set-Cookie: pdfgenerator_cookie=f02f5fdf709ce88a7f31b130029d86e6
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.
Thanks for your research,
comment:19 Changed 16 years ago by
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.
Changed 16 years ago by
Attachment: | wikiprint4.log.gz added |
---|
comment:20 Changed 16 years ago by
Hi, full trac.log is attached as wikiprint4.log.gz. Have good luck!
comment:21 Changed 16 years ago by
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 16 years ago by
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 16 years ago by
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 Changed 16 years ago by
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 2009-05-13 15:30:37,015 Trac[loader] DEBUG: Loading trac.mimeview.php from c:\python25\lib\site-packages\trac-0.11.4-py2.5-win32.egg 2009-05-13 15:30:37,030 Trac[loader] DEBUG: Loading trac.ticket.query from c:\python25\lib\site-packages\trac-0.11.4-py2.5-win32.egg ...
in trac.log.
I'm trying to fix this anyways.
Replying to 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:25 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:26 Changed 16 years ago by
Confirmed, both attachment image and graphviz generated image are displayed correctly! Thank you very much!
Should be fixed with r5700, chan you check please?