URL Protection and Access Control #1172

New Issue

2026-10-05T00:34:22+02:00

adam commented

2026-10-05 00:34:22 +02:00

Hi, is it possible that URL protection just does not work?

What I've done

set $conf['original_url_protection'] = 'all';, so images (and other media) get referenced via i.php instead of direct links
set $conf['derivative_url_style'] = 2;, so the same happens to derivatives (i.e. resized cached copies in /_data/i/)
Protected /upload, /galleries and /_data/i with .htaccess (Deny from all).
Searched the documentation
Read the TakeATour info

For Advanced Users

In Piwigo, you can protect the original photos using your local configuration. Use the variable $conf['original_url_protection']: by default empty, you set the value to "images" to protect only the photos or "all" to protect also all type of media, which can be ressource consumming or might simply don't work on your server.

This option works for public and private content. This option currently requires you to deny the acces to the folders /upload and /galleries, by using an .htaccess file (usually a text file with "Deny from all" for content) or the server configurations.

Please note that filenames of photos uploaded using other method than FTP are randomized, so they are impossible to guess: that filename and so the path to the original photo can be known only if the visitor has access to a resized version of that photo, like the thumbnail. $conf['original_url_protection'] and denying access to the folders /upload and /galleries are meant to avoid that case.

All images get now loaded through i.php and are otherwise inaccessible via direct links.

The Problem

But: If a user knows a direct link, they can still access the image without logging in, share the link, or even request other variants (i.e., the -xl variant if they know only the -xs link). And is this not what the last sentence in the TakeATour text promises to solve?

I have seen this thread talk about i.php checking against the users session, so users may only access files for which a link has been generated for them. However, it does not seem like any session checks are done in the current i.php whatsoever. Basically it just forwards the image with some extra steps.

Now then, what have we even gained by using the two config options? The URLs have been somewhat randomized before, and directory listing is (obviously) turned off on my server. If that is all that's happening, are we not better off just serving the images statically through the webserver?
Am I missing something? Is there some cache I have to rebuild for the new settings to take effect properly?

If not, this is not real access control, is it? Or is there anything I can do so images only ever get served to logged in users?

Hi, is it possible that URL protection just _does not work_? ### What I've done - set `$conf['original_url_protection'] = 'all';`, so images (and other media) get referenced via `i.php` instead of direct links - set `$conf['derivative_url_style'] = 2;`, so the same happens to derivatives (i.e. resized cached copies in /_data/i/) - Protected /upload, /galleries and /_data/i with .htaccess (`Deny from all`). - Searched the documentation - Read the [TakeATour info](https://github.com/Piwigo/TakeATour/blob/62e395f9388a23406311646a8a131059acb219ca/language/en_GB/tour_privacy.lang.php#L62) > For Advanced Users In Piwigo, you can protect the original photos using your local configuration. Use the variable $conf[\'original_url_protection\']: by default empty, you set the value to "images" to protect only the photos or "all" to protect also all type of media, which can be ressource consumming or might simply don\'t work on your server. This option works for public and private content. This option currently requires you to deny the acces to the folders /upload and /galleries, by using an .htaccess file (usually a text file with "Deny from all" for content) or the server configurations. Please note that filenames of photos uploaded using other method than FTP are randomized, so they are impossible to guess: that filename and so the path to the original photo can be known only if the visitor has access to a resized version of that photo, like the thumbnail. $conf[\'original_url_protection\'] and denying access to the folders /upload and /galleries are meant to avoid that case. All images get now loaded through i.php and are otherwise inaccessible via direct links. ### The Problem **But:** If a user knows a direct link, they can still access the image without logging in, share the link, or even request other variants (i.e., the -xl variant if they know only the -xs link). And is this not what the last sentence in the TakeATour text promises to solve? I have seen [this thread](https://github.com/Piwigo/Piwigo/issues/261#issuecomment-124893435) talk about i.php checking against the users session, so users may only access files for which a link has been generated for them. However, it does not seem like any session checks are done in the current i.php whatsoever. Basically it just forwards the image with some extra steps. Now then, what have we even gained by using the two config options? The URLs have been somewhat randomized before, and directory listing is (obviously) turned off on my server. If that is all that's happening, are we not better off just serving the images statically through the webserver? Am I missing something? Is there some cache I have to rebuild for the new settings to take effect properly? If not, this is not real access control, is it? Or is there anything I can do so images only ever get served to logged in users?

adam commented

2026-10-05 00:34:23 +02:00

I have come across the same problem and can confirm it. Hiding URLs at most hinders people from finding stored images, but does not prevent it. For any person or company that doesn't want to share their images with the whole world, Piwigo is unfortunately not a solution if the server is publicly accessible. 😕

I have come across the same problem and can confirm it. Hiding URLs at most hinders people from finding stored images, but does not prevent it. For any person or company that doesn't want to share their images with the whole world, Piwigo is unfortunately not a solution if the server is publicly accessible. :confused:

adam commented

2026-10-05 00:34:24 +02:00

Same problem and maybe add something like this https://stackoverflow.com/questions/3990337/how-to-protect-against-direct-access-to-images
im no expert and would like to see the url to the direct image be blocked. this will prevent external access. and only be able to download when the download button is visible.

Same problem and maybe add something like this https://stackoverflow.com/questions/3990337/how-to-protect-against-direct-access-to-images im no expert and would like to see the url to the direct image be blocked. this will prevent external access. and only be able to download when the download button is visible.

adam commented

2026-10-05 00:34:25 +02:00

As far as I tried yesterday, creating private library, forcing login and adding URL protection only add a false sense of security.
i.php basically allows to see any existing image variant without being logged in. Only original images are protected so I don't see the point.
If your images names are predictable you are screwed and i.php acts as a trojan horse. Turning off URL protection and having directory listing disabled server-side allows the same level of (false) security with an obvious performance gain.

As far as I tried yesterday, creating private library, forcing login and adding URL protection only add a false sense of security. i.php basically allows to see any existing image variant without being logged in. Only original images are protected so I don't see the point. If your images names are predictable you are screwed and i.php acts as a trojan horse. Turning off URL protection and having directory listing disabled server-side allows the same level of (false) security with an obvious performance gain.

adam commented

2026-10-05 00:34:26 +02:00

i have the same problem
also a logged in user can copy the image url than it only viewable by a logged in user and share it publicly. again breaking security.

i have the same problem also a logged in user can copy the image url than it only viewable by a logged in user and share it publicly. again breaking security.

adam commented

2026-10-05 00:34:26 +02:00

Long time Piwigo user, I've been doing upgrades form times to times but haven't been really looking into the configuration for ages, so I might have missed a step.

I discovered today that users with access to an album could find an image URL and then browse the whole galleries directory, even for albums they are not authorized.

I figured I was missing a .htaccess and searching for this brought me here.

I don't know what "URL protection" is and if I should have enabled it. I added a .htaccess with the following content in the root directory:

Options -Indexes

Images are indeed still readable by any anonymous user knowing their path, so this sucks if directories and files have predictable names. Or if you want to take away some permissions. I think I remember reading that this was deemed acceptable by the author and I don't really mind for my own case.

Reading this thread another time, I realized i.php is meant to fix this. I applied the config in OP

$conf['original_url_protection'] = 'all';
$conf['derivative_url_style'] = 2;

Now the pics are served with an URL like this

/action.php?id=3557&part=e

where the id is just incremented, not even random, so I don't see the benefit at all.

I guess the proper way to go would be preventing direct access (e.g. with htaccess) and accessing images via some random UUID associated to them in the database.

I agree this is arguably a security issue. In fact, if I hadn't seen this thread, I'd have written to the author privately (responsible disclosure).

Long time Piwigo user, I've been doing upgrades form times to times but haven't been really looking into the configuration for ages, so I might have missed a step. I discovered today that users with access to an album could find an image URL and then browse the whole `galleries` directory, even for albums they are not authorized. I figured I was missing a `.htaccess` and searching for this brought me here. I don't know what "URL protection" is and if I should have enabled it. I added a `.htaccess` with the following content in the root directory: ``` Options -Indexes ``` Images are indeed still readable by any anonymous user knowing their path, so this sucks if directories and files have predictable names. Or if you want to take away some permissions. I think I remember reading that this was deemed acceptable by the author and I don't really mind for my own case. Reading this thread another time, I realized i.php is meant to fix this. I applied the config in OP ```php $conf['original_url_protection'] = 'all'; $conf['derivative_url_style'] = 2; ``` Now the pics are served with an URL like this ``` /action.php?id=3557&part=e ``` where the id is just incremented, not even random, so I don't see the benefit at all. I guess the proper way to go would be preventing direct access (e.g. with htaccess) and accessing images via some random UUID associated to them in the database. I agree this is arguably a security issue. In fact, if I hadn't seen this thread, I'd have written to the author privately (responsible disclosure).

Sign in to join this conversation.

master

issue-2560-people

translation

16.x

feat/embedding-based-contextual-tagging

issue-2576-search-include-ai-in-search-results

feat/search-ocr-ai

issue-2391-update-menu-design

15.x

detect-container

issue-2386-update-filters-users-activity

issue-2362-add-filters-options-in-admin

issue-2367-imagemagick7

issue-2225-quicksearch-help

14.x

issue-2164-BatchManagerUnitMode-Redesign

13.x

12.x

issue-1657-SVG_Support

issue-1703-historySearchMethod

11.x

2.10

2.9

2.8

2.7

2.5

2.6

2.4

2.3

2.2

2.1

2.0

1.7

1.3

1.6

1.5

1.4

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/Piwigo#1172