8.1 KiB
4.4.0 (Unreleased)
Overview
- Security patch for SS-2018-022
- Correct PHP types are now returned from database queries
- Server Requirements have been refined:
MySQL 5.5 end of life reached in December 2018, thus SilverStripe 4.4 requires MySQL 5.6+.
SilverStripe 4.3 and prior still support MySQL 5.5 for their own lifetime. - The name of the directory where vendor module resources are exposed can now be configured by defining a
extra.resources-dir
key in yourcomposer.json
file. If the key is not set, it will automatically default toresources
. New projects will be preset to_resources
. This will avoid potential conflict with SiteTree URL Segments. - dev/build is now non-destructive for all Enums, not just ClassNames. This means your data won't be lost if you're switching between versions, but watch out for code that breaks when it sees an unrecognised value!
DevelopmentAdmin controllers
On Live environment all browser based HTTP requests to /dev/*
urls get redirected to a confirmation form.
See more details below in the Upgrading section.
DevelopmentAdmin cli-only mode
DevelopmentAdmin now has CLI-only mode (off by default).
The mode makes all dev/*
controllers to be only accessible from CLI (e.g. sake).
To turn it on you may add the following configuration to your project configs:
SilverStripe\Dev\DevelopmentAdmin:
deny_non_cli: true
Upgrading
Adopting to new _resources
directory
- Update your
.gitignore
file to ignore the new_resources
directory. This file is typically located in the root of your project or in thepublic
folder. - Add a new
extra.resources-dir
key to your composer file.
{
// ...
"extra": {
// ...
"resources-dir": "_resources"
}
}
- Expose your vendor assets by running
composer vendor-expose
. - Remove the old
resources
folder. This folder will be located in thepublic
folder if you have adopted the public web root, or in the root of your project if you haven't.
You may also need to update your server configuration if you have applied special conditions to the resources
path.
DevelopmentAdmin controllers
The security fix for SS-2018-022 introduces a new
Confirmation component and
ConfirmationMiddleware that prevents CSRF based attacks
on the urls placed under dev/*
path.
If you use dev/
endpoints, you may need to consider the following changes:
/dev/confirm
url now holds the confirmation form, where users will have to manually approve their actions- on live environments all non-cli (browser based) HTTP requests to
dev/*
urls get redirected to the confirmation form - ajax requests to
/dev/*
urls will be redirected as well (as such may stop working until configuration is added) GET
andPOST
requests are handled gracefully, but other HTTP methods will be transformed toGET
by the confirmation form- you may add custom configuration for the confirmation middleware to prevent redirection for some requests or URLs
CLI based requests (e.g. sake) are not affected by the confirmation middleware and keep working as is.
If you are a 3rd party module developer and you extend DevelopmentAdmin adding new routes under the dev/
path, you may
need to add custom rules for the confirmation middleware in your module configuration. Otherwise, people navigating
those through browsers will have to confirm every single action, which may impair user experience significantly.
You may find a configuration example in the framework _config/requestprocessors.yml
file, named dev_urls-confirmation-exceptions
.
ErrorControlChainMiddleware is deactivated
ErrorControlChainMiddleware has been deactivated and deprecated. It is going to be removed in SilverStripe 5.0.
That means uncaught exceptions and fatal errors will no longer trigger flush
on live environments.
The main historic purpose of ErrorControlChainMiddleware was to detect the application state in which manifest cache is incompatible with the source code, which might lead to fatal errors or unexpected exceptions. The only way this can happen is when manifest cache has been generated and application source code files change afterwards. The only reasonable cause for that on live environments would be application deployment.
Ideally, you should avoid reusing manifest cache between different application deploys, so that every newly deployed
version generates its own manifest cache. However, if that's not the case, you may want to consider using
SS_FLUSH_ON_DEPLOY
setting, which automatically triggers flush
on every deploy by comparing filesystem modification
time with cache generation timestamp. This effectively eliminates the possibility for the manifest cache to be incompatible
with the deployed app.
In that case you may consider using `SS_FLUSH_ON_DEPLOY`. Depending on your deployment tooling you may point it to a filesystem resource that gets modified on every deploy update so that the framework will automatically perform `flush` for you.
The best practice is not to reuse the application manifest cache between deploys.
Changes to internal APIs
PDOQuery::__construct()
now has a 2nd argument. If you have subclassed PDOQuery and overridden __construct() you may see an E_STRICT error- The name of the directory where vendor module resources are exposed can now be configured by adding a
extra.resources-dir
key to your composer file. The new default insilverstripe/installer
has been changed to_resources
rather thanresources
. This allows you to useresources
as a URL segment or a route. SilverStripe\Control\HTTPApplication
now usesFlushDiscoverer
implementers to check forflush
SilverStripe\Control\Middleware\ConfirmationMiddleware
component implementedSilverStripe\Control\Middleware\URLSpecialsMiddleware
component implementedSilverStripe\Control\Director::isManifestFlushed
static function implementedSilverStripe\Core\CoreKernel::isFlushed
function keeps boolean whether manifest cache has been flushedSilverStripe\Core\Environment::isCli
method is now responsible for low level CLI detection (on before the kernel boot stage).Director::is_cli
is still to be used on the application level.SilverStripe\Core\Startup\ErrorControlChainMiddleware::__construct
has a 2nd argument which activates its legacy behaviourSilverStripe\Core\Startup\FlushDiscoverer
interface and a number of its implementations in the same namespaceSilverStripe\Dev\DevConfirmationController
implements the confirmation form for the/dev/confirm
endpointSilverStripe\Dev\DevelopmentAdmin
now hasdeny_non_cli
configuration parameterSilverStripe\Security\Confirmation
component implemented
Deprecations
SilverStripe\Control\Director::isManifestFlushed
SilverStripe\Core\CoreKernel::getEnvironment
SilverStripe\Core\CoreKernel::sessionEnvironment
SilverStripe\Core\Startup\AbstractConfirmationToken
SilverStripe\Core\Startup\ConfirmationTokenChain
SilverStripe\Core\Startup\ErrorControlChain
SilverStripe\Core\Startup\ErrorControlChainMiddleware
SilverStripe\Core\Startup\ErrorDirector
SilverStripe\Core\Startup\ParameterConfirmationToken
SilverStripe\Core\Startup\URLConfirmationToken