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

eZ debug

Timing:	Jan 18 2025 10:25:59
Script start
Timing:	Jan 18 2025 10:25:59
Module start 'layout'
Timing:	Jan 18 2025 10:25:59
Module start 'content'
Timing:	Jan 18 2025 10:26:00
Module end 'content'
Timing:	Jan 18 2025 10:26:00
Script end

Main resources:

Total runtime	0.9787 sec
Peak memory usage	4,096.0000 KB
Database Queries	57

Timing points:

Checkpoint	Start (sec)	Duration (sec)	Memory at start (KB)	Memory used (KB)
Script start	0.0000	0.0054	588.0469	152.6406
Module start 'layout'	0.0054	0.0027	740.6875	39.4766
Module start 'content'	0.0081	0.9686	780.1641	554.0078
Module end 'content'	0.9767	0.0019	1,334.1719	12.1250
Script end	0.9787		1,346.2969

Time accumulators:

Accumulator	Duration (sec)	Duration (%)	Count	Average (sec)
Ini load
Load cache	0.0032	0.3263	16	0.0002
Check MTime	0.0013	0.1305	16	0.0001
Mysql Total
Database connection	0.0007	0.0678	1	0.0007
Mysqli_queries	0.9216	94.1630	57	0.0162
Looping result	0.0006	0.0647	55	0.0000
Template Total	0.9479	96.9	2	0.4740
Template load	0.0020	0.2051	2	0.0010
Template processing	0.9459	96.6473	2	0.4729
Template load and register function	0.0001	0.0144	1	0.0001
states
state_id_array	0.0012	0.1263	1	0.0012
state_identifier_array	0.0010	0.1032	2	0.0005
Override
Cache load	0.0016	0.1641	28	0.0001
Sytem overhead
Fetch class attribute can translate value	0.0007	0.0675	2	0.0003
Fetch class attribute name	0.0012	0.1185	5	0.0002
XML
Image XML parsing	0.0014	0.1465	2	0.0007
class_abstraction
Instantiating content class attribute	0.0000	0.0015	6	0.0000
General
dbfile	0.0011	0.1089	23	0.0000
String conversion	0.0000	0.0010	4	0.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

Usage	Requested template	Template	Template loaded
1	node/view/full.tpl	full/forum_topic.tpl	extension/sevenx/design/simple/override/templates/full/forum_topic.tpl
3	content/datatype/view/ezimage.tpl	<No override>	extension/sevenx/design/simple/templates/content/datatype/view/ezimage.tpl
3	content/datatype/view/ezxmltext.tpl	<No override>	extension/community_design/design/suncana/templates/content/datatype/view/ezxmltext.tpl
7	content/datatype/view/ezxmltags/paragraph.tpl	<No override>	extension/ezwebin/design/ezwebin/templates/content/datatype/view/ezxmltags/paragraph.tpl
1	content/datatype/view/ezxmltags/literal.tpl	<No override>	extension/community/design/standard/templates/content/datatype/view/ezxmltags/literal.tpl
4	content/datatype/view/ezxmltags/line.tpl	<No override>	design/standard/templates/content/datatype/view/ezxmltags/line.tpl
1	print_pagelayout.tpl	<No override>	extension/community/design/community/templates/print_pagelayout.tpl
Number of times templates used: 20 Number of unique templates used: 7

Time used to render debug report: 0.0001 secs