Move to canLogin in the authentication check. Protected isLockedOut
Enable login to be called with a different login service (CMSLogin), enabling CMS Log in. Seems the styling and/or output is still broken.
logOut could be managed from the Authenticator instead of the member
Authenticators is now a map of keys -> service names. The key is used
in things such as URL segments. The “default_authenticator” value has
been replaced with the key “default” in this map, although in time a
default authenticator may not be needed.
IX: Refactor login() to avoid code duplication on single/multiple handlers
IX: Refactor LoginHandler to be more amenable to extension
IX: Fixed permissionFailure hack
his LoginHandler is expected to be the starting point for other
custom authenticators so it should be easier to repurpose components
`of it.
IX: Fix database-is-ready checks in tests.
IX: Fixed MemberAuthenticatorTest to match the new API
IX: Update security URLs in MemberTest
Further down the line, I'm only returning the `Member` on the doLogin, so it's possible for the Handler or Extending Handler to move to a second step.
Also cleaned up some minor typos I ran in to. Nothing major.
This solution works and is manually tested for now. Supports multiple login forms that end up in the correct handler. I haven't gotten past the handler yet, as I've yet to refactor my Yubiauth implementation.
FIX: Corrections to the multi-login-form support.
Importantly, the system provide a URL-space for each handler, e.g.
“Security/login/default” and “Security/login/other”. This is much
cleaner than identifying the active authenticator by a get parameter,
and means that the tabbed interface is only needed on the very first view.
Note that you can test this without a module simply by loading the
default authenticator twice:
SilverStripe\Security\Security:
authenticators:
default: SilverStripe\Security\MemberAuthenticator\Authenticator
other: SilverStripe\Security\MemberAuthenticator\Authenticator
FIX: Refactor delegateToHandler / delegateToHandlers to have less
duplicated code.
The $class variable gets overwritten in the function.
This causes error messages to be less helpful. For example if you setup a has_many but forget the has_one on the other side the error will look something like
`[Emergency] Uncaught Exception: No has_one found on class 'SomeObject', the has_many relation from 'SilverStripe\View\ViewableData' to 'SomeObject' requires a has_one on 'SomeObject'`
fixing this gives a more useful error, like
`[Emergency] Uncaught Exception: No has_one found on class 'SomeObject', the has_many relation from 'Page' to 'SomeObject' requires a has_one on 'SomeObject'`
When modules are installed as the webroot,
manifest generation should behave the same way as when they're in a subfolder.
Which means accepting the module folder both with a _config/ folder
and a _config.php file present.
Note that our usage of `$asSingleton` in `get()` is fine. Quote from the PSR:
> Two successive calls to get with the same identifier SHOULD return the same value. However, depending on the implementor design and/or user configuration, different values might be returned, so user SHOULD NOT rely on getting the same value on 2 successive calls.
Regression introduced through https://github.com/silverstripe/silverstripe-framework/issues/6362.
Quote from the RFC:
```
Thus the order of action precedence becomes
action callback
action on the Form
action on the FormRequestHandler
action on any parent controller (if given)
```
* Test databases now include timestamp for easier debugging
* Use classname::class instead of string literal classnames
* Remove DataObject::get_one() from SapphireTest
* More fixes to ICU DB inconsitency for time formatting
* Correctly restore PHPUnits error handler
FIX for #4417: Ensuring ->removeValidation() is defined on instances of Validator. Setup new API for enabling/disabling validation. Documentation and better type handling.
