| Previous · Next | |
| User | Message |
|
knowmad
|
Date: 2/6/2008 10:34 pm · Subject: Protecting File Assets · Rating: -2
I need to find a way to protect files that does not just protect the friendly url but also protects the real file location. As you know, WebGUI::Asset::File's www_view method does a redirect to the storage location. At this point, there is no security. I recall some discussions around this issue but do not remember if any workarounds or other ideas came out. Suggestions? EDIT: After posting this message, I came across the following links: Wiki article by Martin - What to do if privileges on the uploads directory don't seem to work Martin's suggestion in his wiki entry worked for me, but I don't understand Graham's response that this technique imposes severe performance issues.
---- |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 2/6/2008 11:10 pm · Subject: Re: Protecting File Assets · Rating: 1
Check the wikiJT On Feb 6, 2008, at 10:34 PM, <william@knowmad.com> wrote: knowmad wrote:
|
| Back to Top |
Rate [ | ]
|
|
knowmad
|
Date: 2/6/2008 11:15 pm · Subject: Re: Protecting File Assets · Rating: -2
Check the wiki I was updating my original post as you responded. Could you respond to my question about the performance issues this technique brings up?
---- |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 2/7/2008 8:45 am · Subject: Re: Protecting File Assets · Rating: -5
Martin's answer in the wiki is the right answer 100%. If you want file protection, you turn it on. As far as performance, here's the difference. With modproxy only: modproxy > return file Going through webgui: modproxy > modperl > look at .wgaccess > load session > connect to db > instanciate asset > check privs > return file As you can see a lot more goes on there. On a single request, you're not likely to notice the performance hit as this whole process has ben heavily optimized. However, on a busy site, you'll see the site perform slower than you would without it. It's certainly usable, or we wouldn't put it in there. But for most sites, there's no reason to take the performance hit. |
| Back to Top |
Rate [ | ]
|
|
knowmad
|
Date: 2/8/2008 8:22 am · Subject: Re: Protecting File Assets · Rating: 7
Thanks for the detailed answer JT. Now, let me throw out an idea. Could there be a way to allow for protection of some files through the above mechanism but let other files be served by the faster, mod_proxy method? Perhaps a custom File Asset that uses a different directory for storing it's files?
William ---- |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 2/15/2008 11:32 am · Subject: Re: Protecting File Assets · Rating: 4
Anything is possible of course. But this isnt something i would likely want in the core, because it puts an unnecessary burden on the user. JT On Feb 8, 2008, at 8:22 AM, <william@knowmad.com> wrote: knowmad wrote:
|
| Back to Top |
Rate [ | ]
|
|
knowmad
|
Date: 2/15/2008 4:17 pm · Subject: Re: Protecting File Assets · Rating: -2
Anything is possible of course. But this isnt something i would likely want in the core, because it puts an unnecessary burden on the user. Looking in WebGUI::Asset::File at the setStorageLocation method, it is using WebGUI::Storage. So I'll need to subclass both File.pm and Storage.pm in order to override the default storage location. Would you accept a patch to core that would allow Storage's _makePath to accept an alternative directory for $node instead of always relying on $self->session->config->get("uploadsPath")? If I could pass in an alternate config setting via the create method, I'd be 90% of the way towards having a file asset that can store to a secure location. This alternate location would need to be handled by getPath() and delete() as well. Now the next question is how hard will it be to retrieve the file from this alternate location? Or would the path be stored with the new asset so that this would not be an issue?
William ---- |
| Back to Top |
Rate [ | ]
|
|
martink
|
Date: 2/15/2008 11:32 am · Subject: Re: Protecting File Assets · Rating: 3
I have thought about this too lately. What if files viewable for 'Everyone' do not get a .wgaccess file. In that case no session will be built and the only performance hit you suffer is the '-e .wgaccess' check. A .wgaccess file doesn't make sense for Everyone-viewable files anyway. I think such behaviour can be easily built into WG::Storage->setPrivileges. Martin william@knowmad.com wrote: > knowmad wrote: > > Thanks for the detailed answer JT. > > Now, let me throw out an idea. Could there be a way to allow for > protection of some files through the above mechanism but let other > files be served by the faster, mod_proxy method? Perhaps a custom File > Asset that uses a different directory for storing it's files? > > > > William > > ---- > Knowmad Technologies > http://www.knowmad.com > > > > http://www.plainblack.com/webgui/dev/discuss/protecting-file-assets/4 > ------------------------------------------------------------------------ > > > > |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 2/15/2008 11:41 am · Subject: Re: Protecting File Assets · Rating: 3
It already short circuits for files with an Everyone viewable group.On Feb 15, 2008, at 11:32 AM, <martin@oqapi.nl> wrote: martink wrote: JT Smithph: 703-286-2525 x810fx: 312-264-5382 Create like a god. Command like a king. Work like a slave. |
| Back to Top |
Rate [ | ]
|
|
knowmad
|
Date: 2/15/2008 12:01 pm · Subject: Re: Protecting File Assets · Rating: -11
It already short circuits for files with an Everyone viewable group. Does that mean that when we use Martin's technique of allowing the modperl server to serve images, the process you described above only happens if the file is protected? At which stage in that process does wG short-circuit everyone-viewable files?
William ---- |
| Back to Top |
Rate [ | ]
|
