How to deny access to image original size/alias?

Previous topic

Developer

Next topic

Author	Message
Piotrek Karaś	Thursday 01 October 2009 8:37:19 am Hello all, I'm trying to deny public access to the original versions/aliases of uploaded images. Here's what I've come up so far (.htaccess/apache): RewriteCond %{REQUEST_URI} ^/var/self/storage/images(.)\.(jpe?g?\|gif\|png)$ RewriteCond %{REQUEST_URI} !_(small\|large)\.(jpe?g?\|gif\|png)$ RewriteRule . - [F,L] where <i>small\|large...</i> is a list of publicly available alias names (those defined in image.ini). <b>Can you see any problems with that? Do you know any alternative solutions?</b> By the way, I was wondering. Shouldn't securing the original become a standard? In many scenarios original size aliases hold a high quality/resolution images without protection such as watermarks etc. And their name is very easy to assume from other alias filename variations... Thanks, Piotrek -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu
Gaetano Giunta	Thursday 01 October 2009 9:24:12 am The 'standard' way to secure images would be to have them accessible only via content/download, as for other binary attributes. That would unfortunately put a huge load on the webserver, and make the whole website feel slower, as the standard index.php controller file takes too much memory and time to execute. For particular use cases, you can build a lightweight controller file, similar to the one used for serving images in cluster configurations, that servers images after checking if the user has a valid session cookie and if in his sessions data there is enough information present to identify him as having 'enough access rights' without having to load any eZP classes. Unfortunately the way php serializes session data + the way eZP stores profile information makes it a bit tricky for complex authorization configurations. You can of course build a new datatype that stores the original image in a different folder from its variations, but sites often require different types of access to the different variations (eg. did the user buy the hi-res version?) Principal Consultant International Business Member of the Community Project Board
Piotrek Karaś	Thursday 01 October 2009 9:55:59 am Hello Gaetano, Thanks a lot for your ideas. Dedicated image view did come to my mind, but just as you mentioned it is not performance wise. Cluster mode thing - not much experience, I will have to investigate that direction to get some ideas. Thanks for pointing to that direction though. The idea with a dedicated datatype escaped me somehow and actually it's a most suitable one, I think. It's just a matter of decision - a hack or a datatype with classes extending the existing ones (probably alias handler?)... Might be important for future updates, isn't it? And no, I don't need to put any business logic related to this (such as more advanced access control - I think that could easily use a dedicated view to deliver image as a purchased good). Thanks, Piotrek -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu

Author

Message

Piotrek Karaś

Thursday 01 October 2009 8:37:19 am

Hello all,

I'm trying to deny public access to the original versions/aliases of uploaded images. Here's what I've come up so far (.htaccess/apache):

RewriteCond %{REQUEST_URI} ^/var/self/storage/images(.)*\.(jpe?g?|gif|png)$
RewriteCond %{REQUEST_URI} !_(small|large)\.(jpe?g?|gif|png)$
RewriteRule .* - [F,L]

where <i>small|large...</i> is a list of publicly available alias names (those defined in image.ini).

<b>Can you see any problems with that?
Do you know any alternative solutions?</b>

By the way, I was wondering. Shouldn't securing the original become a standard? In many scenarios original size aliases hold a high quality/resolution images without protection such as watermarks etc. And their name is very easy to assume from other alias filename variations...

Thanks,
Piotrek

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Gaetano Giunta

Thursday 01 October 2009 9:24:12 am

The 'standard' way to secure images would be to have them accessible only via content/download, as for other binary attributes.
That would unfortunately put a huge load on the webserver, and make the whole website feel slower, as the standard index.php controller file takes too much memory and time to execute.

For particular use cases, you can build a lightweight controller file, similar to the one used for serving images in cluster configurations, that servers images after checking if the user has a valid session cookie and if in his sessions data there is enough information present to identify him as having 'enough access rights' without having to load any eZP classes. Unfortunately the way php serializes session data + the way eZP stores profile information makes it a bit tricky for complex authorization configurations.

You can of course build a new datatype that stores the original image in a different folder from its variations, but sites often require different types of access to the different variations (eg. did the user buy the hi-res version?)

Principal Consultant International Business
Member of the Community Project Board

Piotrek Karaś

Thursday 01 October 2009 9:55:59 am

Hello Gaetano,

Thanks a lot for your ideas.

Dedicated image view did come to my mind, but just as you mentioned it is not performance wise. Cluster mode thing - not much experience, I will have to investigate that direction to get some ideas. Thanks for pointing to that direction though.

The idea with a dedicated datatype escaped me somehow and actually it's a most suitable one, I think. It's just a matter of decision - a hack or a datatype with classes extending the existing ones (probably alias handler?)... Might be important for future updates, isn't it?

And no, I don't need to put any business logic related to this (such as more advanced access control - I think that could easily use a dedicated view to deliver image as a purchased good).

Thanks,
Piotrek