Closed Zaita closed 5 years ago
That could be an issue, but please read the upgrading document. At the end:
Invalid command 'Require', perhaps misspelled or defined by a module not included in the server configuration, or Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration - load module mod_access_compat, or update configuration to 2.4 authorization directives.
So you need to load the access_compat module. ( just checked, its still there in the apache2 2.4.39-2.1 rpm on opensuse tumbleweed )
But i do agree that it's good to update the default .htaccess and documentation and start using the new directives.
Hi Dirk, Thanks for this. I'm working around it with some docker containers, but good to know its still in Tumbleweed.
S.
Do you think we should update the Apache config file or the documentation? Would one of you be keen to make a pull request?
My preference would be the .htaccess files, as this issue is going to be more common going forward as deployments of apache don't by default enable the compat mode. This is how I discovered it, I did an update in the weekend and tried to deploy SS today.
I unfortunately do not have the knowledge of SS to make a pull request at this point.
I'm not sure where that .htaccess comes from. If you have a location, maybe in the cms, that would be helpfull. I could check it and try to make a suggestion on the changes needed. You would probably need a backward-compatible check in there too.
Are we talking about the assets htaccess file? If so it’s generated from a .ss template which you could find by searching for the comment in the output file, it’s ProtectedAdapter.ss or something- sorry I’m not at a computer right now
I found the .htaccess in these repo/files
framework/src/Dev/Install/Installer.php silverstripe/recipe-core/public/.htaccess
That's something else than @robbieaverill suggested. Am I missing something?
@derkgort I believe Robbie is referring to this pair of templates which are used to generate .htaccess
files in the assets directory:
They don’t seem to use Order
, so should be okay.
But the first does use "Deny from all". Which comes from the same depricated module/functions. Good to know.
FWIW, I enabled mod_access_compat on my installation and it would not allow me to access any of the SS installation files. It seems to have some weird behaviour.
All in all, I have to modify /public/.htaccess /public/assets/.htaccess /public/resources/,htaccess
in order to get it to function.
What did you change? And what kind of "weird" behaviour?
In /etc/sysconfig/apache2 I enabled access_compat Note: /etc/apache2/loadmodule.conf is not used
Then I'd get 403 Access denied across the board. When I changed the .htaccess files to Require all denied to replace the Order/Allow/Deny directives everything works. This is still a bit of a hassle as when the .htaccess files are generated it stops things working (installation etc) until you correct the file manually.
My DocumentRoot is /SDLT/public/
Just had a read through all the wonderful comments. Here's what I took away. Let me know if I missed anything important.
Require
directive to replace Order
, Deny
, Allow
.Require
directive is managed by mod_authz_host
. If you want the old directives to keep working you can enable mod_access_compat
... which most Linux distros seem to be doing out of the box.mod_access_compat
by default, which means that the default .htaccess
files that ship with your standard SilverStripe install won't work out of the box. People in that boat can solve their problem by either:
mod_access_compat
.htaccess
files (including asset's htaccess template) to use the newer directive.Require
directive.Require
over Deny/Allow
.htaccess
filesRequire
.
mod_authz_host
disabled ... would need override their HTACCESS SS templates.Our doc says we support Apache 2.0+ with mod_rewrite and "AllowOverride All" set
I've since rewritten the server requirements, and it no longer spells out which Apache version we support. Because specific statements like that get us into trouble, and don't age well. In the end, we provide some starting points for configuring your hosting environment, but it is not the primary responsibility of a PHP web framework to ensure compatibility with webservers.
Apache 2.2 calling it a "final release" is just another way of saying end of life, meaning they no longer provide security fixes. So this isn't really a discussion. We have a bug in our framework (current version of Apache breaks), and we should fix it to be compatible with the minimum supported version of Apache (2.4).
Some internal risk assessments on this in https://silverstripe.freshdesk.com/a/tickets/57550.
Here's the section relevant to where we apply those protections in CWP and core modules:
Deny access to .ss and .yaml (potentially sensitive config values) everywhere
Deny access to *.php in app/ folder
Deny access to *.php in CWP 1.x (3.x) core modules
Note: All supported modules in CWP 2.x (4.x) have shifted to composer-managed directories in vendor/, which prevents access via a highlevel .htaccess file rather than module specific .htaccess files. This new style of writing modules is still opt-in, so there might be modules out there which are still affected (just not ours).
Not affected:
Of all modules installed as part of cwp-recipe-kitchen-sink
, there are the following .htaccess
files:
$ find . -name '.htaccess'
./public/resources/.htaccess
./public/.htaccess
./app/.htaccess
./.htaccess
./vendor/cwp/cwp-installer/public/assets/.htaccess
./vendor/cwp/cwp-installer/app/.htaccess
./vendor/cwp/cwp-installer/.htaccess
./vendor/silverstripe/recipe-core/public/.htaccess
./vendor/silverstripe/recipe-core/app/.htaccess
./vendor/silverstripe/recipe-core/.htaccess
./vendor/silverstripe/recipe-cms/.htaccess
./vendor/silverstripe/vendor-plugin/resources/.htaccess
./vendor/silverstripe/campaign-admin/client/.htaccess
Missing from this list because it's a SilverStripe template that generates a .htaccess
file:
./vendor/silverstripe/assets/templates/SilverStripe/Assets/Flysystem/ProtectedAssetAdapter_HTAccess.ss
cwp/cwp-installer
: ~https://github.com/silverstripe/cwp-installer/pull/27~ https://github.com/silverstripe/cwp-installer/pull/28silverstripe/recipe-core
: https://github.com/silverstripe/recipe-core/pull/49silverstripe/recipe-cms
: unaffected.silverstripe/vendor-plugin
: https://github.com/silverstripe/vendor-plugin/pull/30silverstripe/campaign-admin
: unaffected.silverstripe/assets
: https://github.com/silverstripe/silverstripe-assets/pull/334Not going to patch SS3 modules, they're out of support save for security issues.
For the Common Web Platform (where SS3 is still in a sort of support), SilverStripe Ltd is the vendor and controls that infrastructure. Unless a security issue arises because of the compatibility module I think the value return is overly minimal.
Not going to patch SS3 modules, they're out of support save for security issues.
Yep, fair call. This is only a security issue if a server is misconfigured (not running the Apache compat module which is required for what's now effectively a legacy SilverStripe release)
All PR's open, CI green. 💚 Calling this done.
Just waiting for mergers before closing #9001 💜
FYI I tried disabling mod_authz_host
on my Ubuntu install just to see what kind of error you would get. I got some pretty nasty warning and Apache wouldn't even restart afterwards. So I think it's a pretty safe assumption that no one out there is running Apache 2.4 without support for Require
.
WARNING: The following essential module will be disabled.
This might result in unexpected behavior and should NOT be done
unless you know exactly what you are doing!
authz_host
To continue type in the phrase 'Yes, do as I say!' or retry by passing '-f':
Peer reviewed the 2 other PRs.
I'm thinking we probably need to get everythign merge and do a test run on SSP and CWP.
Tested on SSP and CWP. Everything works fine.
This issue has been worked on as part of a larger initiative focused on reducing the experience debt of the SilverStripe CMS.
Thank you for taking the time to raise this issue and/ or provide feedback supporting the implementation.
This is an initiative from the teams maintaining the commercially supported module list. If you're interested to read more about this initiative and keep up with our progress have a look at our blog post on experience debt.
Affected Version
Apache 2.4.39+
bigfork/silverstripe-oauth-login 2.0.0 SilverStripe logins via OAuth2, using the PHP League's OAuth2 client dnadesign/silverstripe-populate 2.0.0 Populate your database through YAML files friendsofphp/php-cs-fixer v2.15.0 A tool to automatically fix PHP code style lekoala/silverstripe-debugbar 2.0.3 DebugBar for SilverStripe CMS phpro/grumphp v0.14.3 A composer plugin that enables source code quality checks. phpunit/phpunit 5.7.27 The PHP Unit Testing framework. ramsey/uuid 3.8.0 Formerly rhumsaa/uuid. A PHP 5.4+ library for generating RFC 4122 version 1, 3, 4, and 5 universally unique identifiers (UUID). sensiolabs/security-checker v5.0.3 A security checker for your composer.lock silverstripe/graphql-devtools dev-master d73f56c Tools to help developers building new applications on SilverStripeâs GraphQL API silverstripe/postgresql 2.2.0 SilverStripe now has tentative support for PostgreSQL ('Postgres') silverstripe/recipe-cms 4.3.0 SilverStripe recipe for fully featured page and asset content editing silverstripe/recipe-plugin 1.3.0 Helper plugin to install SilverStripe recipes squizlabs/php_codesniffer 3.4.2 PHP_CodeSniffer tokenizes PHP, JavaScript and CSS files and detects violations of a defined set of coding standards. symbiote/silverstripe-gridfieldextensions 3.2.1 A collection of useful grid field components symbiote/silverstripe-queuedjobs 4.4.0 A framework for defining and running background jobs in a queued manner thenetworg/oauth2-azure v1.4.2 Azure Active Directory OAuth 2.0 Client Provider for The PHP League OAuth2-Client unclecheese/display-logic 2.0.2 Allows assignment of conditions for display and hide of specific form fields based on client side behavior.
Description
SilverStripe is still using Order, Deny, Allow directives in .htaccess files. This was deprecated with the release of Apache 2.4 and has finally been removed as of 2.4.39 causing SilverStripe to no longer work.
https://httpd.apache.org/docs/2.4/howto/access.html https://httpd.apache.org/docs/2.4/upgrading.html
Steps to Reproduce
Run SilverStripe with Apache 2.4.39 or later. I'm using OpenSUSE Tumbleweed
Osiris:~ # cat /etc/os-release NAME="openSUSE Tumbleweed"
VERSION="20190512"
ID="opensuse-tumbleweed" ID_LIKE="opensuse suse" VERSION_ID="20190512" PRETTY_NAME="openSUSE Tumbleweed" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:tumbleweed:20190512" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" LOGO="distributor-logo"
Error in Apache Log: /SDLT/public/resources/.htaccess: Invalid command 'Order', perhaps misspelled or defined by a module not included in the server
Pull requests