>>> Yes, it definitely did work, see this thread from back in 2009: >>> >>> http://groups.google.com/group/turbogears/browse_thread/thread/881e2dc56da64d44 >> >> Actually now I'm not entirely sure anymore, according to >> http://turbogears.org/1.1/docs/StaticFiles.html#protecting-static-files-via-identity >> it didn't work with tg 1.1. Maybe it only worked with tg 1.0? > > I've looked a bit into this now. > > First, only 'visit' is a CherryPy tool - 'identity' is not. The identity > mechanism is called indirectly via the visit tool when enabled with the > global 'identity.on' config setting. > > Second, the visit tool is set up using the before_handler hook. The > static tool of CherryPy uses the same handler, but is hooked up before, > so static requests bypass the visit/identity handler. > > Third, theoretically, we could rewire the visit tool with a priority > value below 50, then it would be called before the static tool. > > But this would still not help us, because identity protection only kicks > in when you have a predicate that is activated by a require decorator or > a secure resource, but you don't have these when dealing with static > resources. The config setting "identity.require" mentioned in the old > thread only wires default predicates to secure resources, but that is > (and was) of no use for static resource.
I see, thanks for the detailed explanation. It seems to me it should be possible to rewrite things a bit in a way that static resources also define predicates somewhere somehow (for example in config/app.cfg) or predicates are very deeply tied to the require decorator or secure resources? > So the only solution I see is to serve your static files from a secure > resource, as implemented in the recipe you mentioned for TG 1.1. It will > probably need some small adaptation for TG 1.5. I have currently not > enough time to rewrite that recipe, but if you or somebody else can do > it, I will add it to the TG 1.5 docs. Should not be difficult. I agree this is an option and perhaps the only option at the moment, will look into it. Ideally though, it would be nice to have predicates for static resources, so that identity checks kick in, if unauthorized the request is denied, if authorized the usual file serving kicks in but with the option of having the static resource served by another web server like nginx or lighttpd. This is actually my main problem with the recipe solution, that the file is then served by cherrypy when I'd like to have the faster option of nginx or some such. But I understand that in order to have this some major rewriting needs to be done. > You should also consider whether it is really needed to protect your > static files. The static resources are often served directly via the > webserver in production, because this is much more performant, and then > they cannot be protected by the identity system anyway. This is really the case? Then forget my previous paragraph, this is exactly what I outlined I wished to have. Too bad I guess :) > Or maybe it > suffices to protect only some critical files, via the recipe above, or > vua a simple protected controller serving the static file. In my application the static files are media files that users uploaded and they can choose who to share it with. My guess was that I should set identity predicates for the static resources but for good performance have a separate web server serve these. Cheers, Daniel > -- Christoph > > -- > You received this message because you are subscribed to the Google Groups > "TurboGears" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/turbogears?hl=en. > > -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
