-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: add standard configuration for nginx on the instructions or README #8
Comments
The docker container I initially created used Nginx until I realized the permissions weren't supported. Gallery currently requires .htaccess files for any content that has permissions enabled and nginx/php-fpm doesn't support that. As a workaround all content could be routed through the /file_proxy/ path although I think this wouldn't be as performant as gallery would be handling all file requests instead of leaving that to the web server: For reference here is the Nginx config I had previously in the docker setup: |
Aye, I'm well-aware of the existence of so much PHP software written with the assumption that they can offload all heavy-duty security tasks to simple Apache rewrites on I guess that the whole permission systems need to be overhauled, then. Since I don't use them (probably because I was used to Gallery 2 that I wasn't even aware that there was such a concept as 'permissions' in Gallery 3), I have been able to use Delegating permissions to the webserver as opposed to dealing them in the code — beyond the obvious cases — is not really a sustainable, long-term solution. A decade ago, Apache changed considerably how the configuration files were written. What seemed to be 'minor' changes did really affect how certain security/permissions declarations were being interpreted, and we can still find today information about how to convert from the 'old' format to the 'new' (which is not so new...) one. Interestingly, Gallery seems to be already using an alternate mechanism to Or, alternatively, all security issues could be handled by a special (to be developed) Gallery module using, say, the ability to prepend a PHP file to all requests — where all the perm(issions magic would be handled... Oh well, I digress; I really have no idea how the permission system works. All I know is how to convert some |
This message was duplicated from the above one |
Gallery supports Apache, straight out of the box.
nginx
, however, is another completely different beast. It took me literally years to get it right... namely, to find a 5-year-old working configuration (aye, there are hundreds of solutions out there, most of which too outdated, straight 'conversions' from the Apache rewrite rules (which are ugly and rarely efficient) or even using the dreadfulif
statement, which is not supposed to be used.Because it's so hard to get Gallery3 working under
nginx
, I'd love to request that a working configuration for nginx is added on the installation instructions (or on a separate file). I'd add it to the old Wiki, but, alas, I'm aware that there is no access for the common rabble such as myself... 😉Anyway, the following solution by @jonmiller works: http://jonamiller.com/2015/02/15/gallery3-on-nginx/
Because the Internet is fickle, and sites come and go (his blog only has two entries from 2015, clearly something he has not been updating...), taking into account that all credits are due to Jon Miller, here is the working configuration:
But Jon Miller goes further and explains that the real trick that made all the above work correctly was to change one line on
application/config/config.php
:Incredibly, this is all it takes, and Gallery 3.1.3 will be fully operational under PHP 7.4 (I'm trying to see the hurdles of activating PHP 8.0, but I'm well aware that Gallery 3.1.3 only works up to 7.4)
The text was updated successfully, but these errors were encountered: