Search

For a scientific project I’ll have to build an online archive. It’s mainly an online database for photos of old newspaper comics. So it’s a simple one section setup with images and meta data.

The whole website needs to be password protected and so do the direct image paths: it should only be possible to access the images using the interface for logged-in users — it should not be possible to access the direct image paths. So even if a visitor without login credentials guesses an image URL he should not be able to load the image.

Has anyone ever done something like this?

I was thinking that putting the images outside the root would be a good idea using a special file that checks if a visitor is logged-in and calls the image files. But I’m not sure at all if this will work. Ideas are appreciated!

it should only be possible to access the images using the interface for logged-in users

Is server side authentication not an option?

I was thinking that putting the images outside the root would be a good idea using a special file that checks if a visitor is logged-in and calls the image files. But I’m not sure at all if this will work. Ideas are appreciated!

I have done this before on other non-symphony projects, and I’d recommend readfile as it uses little memory.

@Jonas: I’m not sure about server side authentication but I will have a look.

@Moquan: So you used a “container” file for the authentication of the user that return the needed iamge using the readfile function?

Actually, when I did this (albeit a while ago) I passed all the requests through server-side prosessing. This way I could compress js and css on the fly as well as merging files (to reduce http-requests) and (ugly) css variables. I also did this for image-heavy portfolio sites and I haven’t encountered any problems yet.

Also from what read the readfile function reads the files in 8K chunks at time to avoid memory overflow problems.

So even if a visitor without login credentials guesses an image URL he should not be able to load the image.

You could just make it virtually impossible for someone to guess an image URL by adding a few random characters to its file name. Example: image3_Zq3P7#.jpg. Then, the image name and the random characters would have to be guessed correctly to access the file directly without being logged in.

Well, that would make it harder to find the URL but there is still a chance to guess the URL.

@wisolman By adding random letters to a filename guessing the correct URL would be as hard as guessing a password. But what could happen is that someone with access to the file distributes the URL.

@mqchen - True, but couldn’t someone with proper access distribute the images regardless of the URL?

@Nils - If someone is willing and capable enough to break a six character key in order to get one of these images, might they not concentrate on breaking into the whole site instead?

You have a good point, and considering it is also the method Facebook uses to secure images, it should probably be good enough for most cases.

Couldn’t you use php in a custom datasource to check the session is logged in and only serve the image if true? Couldn’t the datasource ‘filter’ be the JIT image path? Or would an event be how to do that?

Just thinking out loud…

My first thought was along the lines of designermonkey, append the session token to the image URL, then test for the valid session before serving the image.

If using lighttpd is an option for you, have a look at mod_secdownload, especially if you expect lots of requests / large download files.

My first thought was along the lines of designermonkey, append the session token to the image URL, then test for the valid session before serving the image.

For this you’d need PHP and then you could simply use the builtin Session mechanics as well.

I have used a .htaccess redirect to ensure all requests for certain file types get routed through a PHP page that ensures the user is authorised.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details