mirror of
https://github.com/silverstripe/silverstripe-framework
synced 2024-10-22 14:05:37 +02:00
cca6d8e1be
See https://github.com/silverstripe/silverstripe-framework/issues/9232. Also simplifies composer instructions a bit: - Removes composer update --no-dev references, that's a bit of an edge case that people can just discover on getcomposer.org if they need it - Changed example from the unused and oudated silverstripe/forum to silverstripe/blog - Updated example versions to 4.x - Remove "updating composer" section, it now tells you if its out of date - Remove ss-auto-git-ignore module reference. The module hasn't been updated in ages, and it's much less necessary now that all relevant modules are on composer - Add .env example config to getting started docs, I didn't realise it was stripped from the default --prefer-dist composer install
97 lines
4.2 KiB
Markdown
97 lines
4.2 KiB
Markdown
# 4.5.0 (Unreleased)
|
|
|
|
## Overview {#overview}
|
|
|
|
* [Installer UI has been removed](#installer-ui) and offered as a separate module.
|
|
* [Generic login form styling](#login-forms)
|
|
* Removed `use_gzip` option on `HtmlEditorField` which used to compress the rich text editor dependency.
|
|
No longer required since compression is performed as part of the CMS build automatically.
|
|
See (#832)(https://github.com/silverstripe/silverstripe-admin/issues/832)
|
|
|
|
## Installer UI has been removed
|
|
|
|
Until now, core releases of SilverStripe would put drop an `install.php` file in the
|
|
public root that, when accessed with a browser, would offer an installation
|
|
UI prompting the user for all the necessary configuration of your project
|
|
and environment, and validating it before performing the installation.
|
|
|
|
While this may be an important part of the onboarding experience for newcomers
|
|
to SilverStripe, it is an unnecessary artefact and potential security risk
|
|
for the vast majority of developers who install SilverStripe with composer
|
|
and their own environment files.
|
|
|
|
The installer UI will continue to live on under the name "installer-wizard" in a
|
|
[separate package](https://github.com/silverstripe/silverstripe-installer-wizard), which
|
|
can be added incrementally to core recipe installation, using `composer require silverstripe/installer-wizard`.
|
|
It is no longer a commercially supported module.
|
|
|
|
## Archive downloads have been removed
|
|
|
|
SilverStripe has gradually switched from using file archives
|
|
to installation via [Composer](https://getcomposer.org).
|
|
This enabled a much more diverse module ecosystem,
|
|
with clear dependency management and greater ability to
|
|
check and enforce constraints and semantic versioning.
|
|
|
|
Starting with this release, we are no longer publishing `silverstripe/installer`
|
|
as a file archive download on silverstripe.org.
|
|
If your workflow relied on these downloads, please switch to using Composer.
|
|
See [#9232](https://github.com/silverstripe/silverstripe-framework/issues/9232) for details.
|
|
|
|
## Generic login form styling {#login-forms}
|
|
|
|
Login forms in SilverStripe are traditionally embedded in your page template.
|
|
This often requires style adjustments in your website, for example to cover variations
|
|
such as error messages and validation feedback. It also complicates
|
|
more advanced login flows such as multi-factor authentication.
|
|
|
|
Starting with this release, new installations include the
|
|
[silverstripe/login-forms](https://github.com/silverstripe/silverstripe-login-forms)
|
|
module. It provides generic styles which look great without any adjustments.
|
|
You can choose to add your own logo, or customise the templates.
|
|
The URLs to login functionality have not changed (e.g. `Security/login`).
|
|
|
|
Existing SilverStripe websites upgrading to this release can opt in to using
|
|
login forms via composer:
|
|
|
|
```
|
|
composer require silverstripe/login-forms
|
|
```
|
|
|
|
Note that any customisations you might have in `Page.ss` or `Layout/Security.ss`
|
|
no longer apply when this module is installed. If you have customised the login process
|
|
by adding form fields, or through custom handlers such as SAML or LDAP,
|
|
you'll need to review those before starting to use the module.
|
|
|
|
|
|
## New PasswordExpirationMiddleware now proactively invalidates members with expired passwords
|
|
|
|
A new PasswordExpirationMiddleware has been implemented.
|
|
It checks passwords of authenticated users for expiration and either enforces a redirection
|
|
to a change password form, or resets the user for a request being processed (sets current user to null).
|
|
|
|
This is considered to be a security enhancement, but potentially might interfere with some custom logic
|
|
around password expiration if you have it implemented.
|
|
|
|
Ideally you should test your setup when upgrading if you use the password expiration functionality.
|
|
|
|
If you'd like to deactivate the middleware, you can unregister it in your application config like this:
|
|
|
|
```yml
|
|
---
|
|
Name: disable-passwordExpirationMiddleware
|
|
After:
|
|
- '#coresecurity'
|
|
---
|
|
SilverStripe\Core\Injector\Injector:
|
|
SilverStripe\Control\Director:
|
|
properties:
|
|
Middlewares:
|
|
PasswordExpirationMiddleware: null
|
|
```
|
|
|
|
## Deprecation
|
|
|
|
* `PasswordValidator` methods `minLength`, `characterStrength`, and `checkHistoricalPasswords` are now deprecated from
|
|
4.5.0 onwards (previously 5.0).
|