Resolves issue #6788
The AuthenticationMethed is passed in via hidden field as per usual, but due to changes, the fallback authenticator was always the MemberAuthenticator and the actual passed in authenticator was defaulting to an empty string.
This causes an issue when there are multiple authenticators and the default authenticator is _not_ in the allowed authenticators, but is still the default. It caused the getAuthenticator method to return the default MemberAuthenticator to be returned, despite it being disabled.
A second issue around multiple authenticators, was the template using a no-longer used method `getAuthenticatorName`. This method returned a null on the default MemberLoginForm (as nothing was set), causing a Warning.
Because the getAuthenticator and getAuthenticatorName are no longer in
use, I've opted to replace these with a translatable string
`getAuthenticatorName`, to
display the title of the form on the tabs, as per the tabset on
Security_MultiAuthenticatorLogin template.
- has the fields and actions extracted to a separate method, so it's more easily overridable
- Moved the global variable $_REQUEST to getting the info from the controller
- Updated string variables to `::class`
- Updated RequiredFields to be set in the YML, so it's overridable/updatable from either Config or code
- Amending best practices for secure coding to enforce HTTPS
- Add security headers to enforce HTTPS
- Ensure secure cookies are used.
- Added links for testing, changed documentation as part of peer review.
- Arrange headers to work with HTTP interface.
- fixed Cache-Control case
- Added reference to Secure Sessions.
- Replaced Cardinality with unique
- Fixed innacurate reference to decendant.
- Consistent spelling
- Databases over DBMSs
As of SS4 I recommend that we clarify the level of support we provide
for MSSQL. The testing coverage of MSSQL and production use of it in
systems supported by the core team both seems very low.
MSSQL support was a lot more important in a pre-cloud-hosting world, but
these days our recommendation is to run SilverStripe on a stack that its
designed to work with rather than trying to fit it into your existing
hosting infrastructure.
