#6412 closed defect (fixed)
no images/css
Reported by: | Eric Betts | Owned by: | anatoly techtonik |
---|---|---|---|
Priority: | low | Component: | NoAnonymousPlugin |
Severity: | minor | Keywords: | |
Cc: | Trac Release: | 0.11 |
Description
Thank you for writing this plugin, it helps me with having an externally available trac instance. I did notice that css and images don't show up though, which is a problem for external vendors who may think I'm unprofessional. I fixed this by adding '/chrome' to the paths list in filter.py, and I thought it might be a change other people would want as well.
Attachments (0)
Change History (9)
comment:1 Changed 14 years ago by
Owner: | changed from Pedro Paixao to anatoly techtonik |
---|
comment:2 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed in [8146] - try new version.
comment:3 Changed 14 years ago by
Disclaimer: I don't use the plugin or know anything about its code, I just noticed this one change by 'accident' :-)
For the change to make sense, you really need to exclude all /chrome
. Plugins that adds own static resources extend the /chrome
namespace. Most plugins will likely be blocked by your plugin before they get a chance to serve their static content (like my FullBlogPlugin that serves under /chrome/tracfullblog/
, but something like a Theme-type plugin will make the problem quite apparent as that is intended to change the overall layout and look-and-feel for all requests.
comment:4 follow-up: 5 Changed 14 years ago by
Thanks for review. I intentionally did not include all /chrome
requests as the purpose of this plugin is to exclude requests from anonymous users to all Trac parts except login. I am not sure that /chrome/plugin
access will not trigger some plugin code and that the code will not be a source of information leaks.
Do you know how /chrome/plugin
resources are processed?
comment:5 Changed 14 years ago by
Replying to techtonik:
Do you know how
/chrome/plugin
resources are processed?
All /chrome/<something>
is processed by the Trac Chrome module. It looks in static resources for plugins depending on what the plugin has registered. No code is executed on the server, it is a straight resource lookup just as it is for common
and site
which are the two basic locations/namespaces known on to an environment.
comment:6 Changed 14 years ago by
I must admit that I am unable to find information on t.e.o. about how plugins register their resources and where these resources are placed.
comment:7 Changed 14 years ago by
See trac.web.chrome.ITemplateProvider
interface - for this particular purpose get_htdocs_dirs()
method that plugins use to return locations for static resources with corresponding path prefix.
comment:8 Changed 14 years ago by
Need more round tuits. For now documented some behavior at http://trac.edgewall.org/wiki/TracDev/TracURLs
Thanks for report, my static resources are served directly by Apache, so I didn't notice the issue.
Adding /chrome/site and /chrome/common to the exclusion list should be enough to close the issue.