What permissions to prevent direct url access to images?

[kyber]

I have clearly not understood the permission settings instructions. I want to keep my gallery private to family and invited friends so I have configured CPG to disallow visitors, only registered users are allowed to use the system.

However, guessing the url for a photo on my website displays a photograph without any limitations.

For example, this url http://www.otterspace.co.uk/photos/albums/karaterefresh2005/normal__IGP4880.JPG (not one you would guess I appreciate) is completely unrestricted.

I am running on a linux box under apache. I can change permission using chmod via FTP.

Everything in albums is at 777 as is the include directory.

I thought I was onto it in this post but found it unclear. (And, yes, I have read the manual and the fFAQ.) I want to apply the limitation to ALL my images inclucing thumbnails. I do not want anyone not logged in able to access any of the images.

I look after a few heavily modded phpbb forums that feature galleries and they mask the urls to the photos and also prevent direct access to the photos.

If indeed there is not current support (built in or through environmental configuration during installation) in cpg for preventing direct access to photos when supposedly only accessible to registered users then I would take the view that there is a major weakness in the security of the application that should be made clear in the documentation and probably on screen at some point. No doubt it is a major task to modify the application to address this for multiple file types.

Advice appreciated. TIA.

kyber

[Joachim Müller]

Although I'm not sure how someone should be able to guess the full URL of your pics if you have configured your server properly (with indexes turned off), you're correct in assuming that Coppermine doesn't have the feature to prevent anyone from accessing a pic directly if the URL is known (or guessed). This has been discussed in the past already: protecting pics against direct access would have to be done by server means - the pic would have to be created dynamically and dropped after having been delivered. This would cause a huge server load and subsequently extreme slow page loads, making Coppermine a resource monger. Additionally, it would not work on all server setups.
For another project I did I have been looking into creation of images on the fly (that's what would be needed): you can't use it with gallery apps like Coppermine - it burns just too much CPU power. For security reasons, you'd need to have your pics stored outside of the webroot of your (virtual) webhost - not every web hosted account does have this option.
So, if you think that this is an important feature, then I agree: Coppermine is not the right gallery for you. As far as I know, our main "competitors" Menalto gallery and 4images don't have this feature neither (somebody correct me if I'm wrong).

I am running on a linux box under apache.

Actually, it's Apache under Linux

I thought I was onto it in this post but found it unclear.

What thread are you refering to?

I look after a few heavily modded phpbb forums that feature galleries and they mask the urls to the photos and also prevent direct access to the photos.

Then you probably have found your app. A Forum is not a web gallery though - they have different goals and different approaches in reaching it. A Forum can keep regular content from others easily, as it usually contains textual content. Encrypting file names just makes it harder to guess pic names, but not impossible.

then I would take the view that there is a major weakness in the security of the application that should be made clear in the documentation and probably on screen at some point.

If this is your idea of security, then I agree: Coppermine is not secure enough for you.

Joachim

[denny101]

If the images were stored in the database as blobs would it not be much harder for people to steal them?

[Joachim Müller]

Yes, but the performance impact would be huge: your database would become very large and slow. This has already been discussed in detail, please search for the thread discussing it.