plg wrote:

At configuration level, I would like to replace the piwigo_user_infos.enabled_high by piwigo_user_infos.max_size, set to "original" by default. If the user only has "medium", then she can't see the L, XL, XXL and original sizes.

Perfect, but what about custom resizes ?

here is how a generated .htaccess would be:

#has rewrite, no protection, always use derivative urls for search engines
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_FILENAME} -d [OR]
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^.*$ - [L]
RewriteRule ^(.*)$ ../../i.php?/$0 [L,QSA]
</IfModule>

#has rewrite, partial protection of xl,xx, always use derivative urls for search engines
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_FILENAME} -d [OR]
RewriteCond %{REQUEST_FILENAME} -f
RewriteCond %{REQUEST_FILENAME} !^(.*)-(xl|xx)[a-zA-Z0-9_.]*$
RewriteRule ^.*$ - [L]
RewriteRule ^(.*)$ ../../i.php?/$0 [L,QSA]
</IfModule>

#has rewrite, full protection
<IfModule mod_rewrite.c>
RewriteRule ^(.*)$ ../../i.php?/$0 [L,QSA]
</IfModule>

#no rewrite - NEED url_style = script for partial or full protection
deny from all

plg wrote:

Do you mean a custom resize generated by a theme? (I don't know yet how to deal with that, at permission level)

Yes. This is the reason why admins must choose a minimum derivative size for watermarking instead of selecting small/medium etc...

plg wrote:

rvelices, do you think it's possible to have such a protection for Piwigo 2.5 maybe? I mean that "upload", "galleries" and "_data/i" directories are "deny from all" and photos are only sent through i.php ?

Possible yes, but it should be customizable and not on by default. Also expect issues / demands such as

- .htaccess issues (file permission, server not being able to parse ...)
- for movies, it will be very bad to send everything to action.php (apache is able to send ranges and  you can use forward/backward in some players)
- some people moved the location of _data/i AND/OR galleries AND/OR uploads -> expect complicated issues when generating relative paths from/to root to/from these locations

If someone wants to do it ... go for it ...

Just to inform that Gallery sets such a protection : htaccess to [Github] gallery3 file modules/gallery/controllers/file_proxy.php their i.php
it's far from being obvious because i.php will need to check the permissions anyway (user access, size)!

In my experience of protecting content and content access based on permissions, the best and truly only secure way is to have the content  outside  of docroot. Of course  this means  you have to serve the content via php (or some other method that streams it). I have in the past been involved in this for image, video, and audio files.

As much as I like Piwigo (I've been playing with for a couple of weeks) I really would  have loved to  use  it but the inability to secure content is killer for my project. It  is a subscription site with  over 60,000 images and about 2,000 video and audio files. All are owned by individual  users so the content needs to be secure. Currently the site is using gallery2 which I have to admit handles security better than on other gallery software I've evaluated (that being said it has all kinds of other problems).

Again because I would love to be able to use Piwigo I would be more than happy to get involved with this project. I can be emailed at gsrtek@gmail.com

I am sure it comes up a lot (as it is important for some sites), yes anything that can be displayed can be copied. The point is to never display it and keep it out of the docroot so it can not be linked to. In fact for images it is very straight forward, it's bit more difficult for media but I have methods for both.

The following is for an image it was written using Zend Framework but it really doesn't matter what you use.

    /**
     * Sends full size image back to client
     *
     * @param Zend_Controller_Request_Http $request
     * @param Zend_Controller_Response_Http $response
     *
     * @return full size image
     */
   
    public function full(Zend_Controller_Request_Http $request, Zend_Controller_Response_Http $response) {
       
        $id    = $request->getParam('id');
        $locater = new Application_Model_DbTable_ContentLocator();
       
        $locate = $locater->content($id);

        // Get the file which has to be here as we are coming from a thumbnail of it
        // return it raw
        $bits = @file_get_contents($locate->location);
            $response->setHeader('Cache-Control', 'public', true);
                $response->setHeader('Content-type', 'image/jpeg', true);
                $response->setBody($bits);
       
       
    }
   
The interesting part is that using this type of logic you can store an image anywhere I have used it with database blobs.

I've also attached the same method except for downloading an  image (it is better documented)

    public function download(Zend_Controller_Request_Http $request, Zend_Controller_Response_Http $response) {
       
        // id of requested content
        $id = $request->getParam('id');
       
        // get a contentLocator object
        $contentLocator = new Application_Model_DbTable_ContentLocator();
       
        // get all the information we nee for the content
        // content locator is guaranteed to always return a valid location
        // if the content is not found the default "Image Not Found" image is returned
        $contentLocation = $contentLocator->content($id);
       
        // supress errors as there should not be any
        $bits = @file_get_contents($contentLocation->location);
       
        // set the headers and return the image
        $response->setHeader('Cache-Control', 'public', true);
        $response->setHeader('Content-Disposition: attachment;filename=' . "\"{$contentLocation->name}\";", true);
        $response->setHeader('Content-type', 'image/jpeg', true);
        $response->setBody($bits);
       
    }
   

Also Application_Model_DbTable_ContentLocator() constructor optionally can take a Permissions($userId, $contentId) object which is an abstract object that the locator uses to decide if the requester has the appropriate permissions to perform certain actions (ie: view, edit, delete, etc). The locator then returns either the requested image or an appropriate image with an error message. All very neat and clean and easily extensible.

Food for thought

Last edited by garyR (2013-09-14 18:26:09)