silverstripe-framework/_config/security.yml

SilverStripe\Security\MemberAuthenticator\LoginForm:
  required_fields:
    - Email
    - Password

SilverStripe\Security\Security:
  authenticators:
    default: SilverStripe\Security\MemberAuthenticator\Authenticator
    cms: SilverStripe\Security\MemberAuthenticator\CMSAuthenticator

SilverStripe\Security\MemberAuthenticator\CMSSecurity:
  reauth_enabled: true
Refactoring of authenticators 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. 2017-04-22 06:30:10 +02:00			`SilverStripe\Security\MemberAuthenticator\LoginForm:`
Improve the default LoginForm - 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 2017-04-14 06:21:38 +02:00			`required_fields:`
			`- Email`
Refactoring of authenticators 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. 2017-04-22 06:30:10 +02:00			`- Password`

			`SilverStripe\Security\Security:`
			`authenticators:`
API: Security.authenticators is now a map, not an array 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 2017-04-23 05:30:33 +02:00			`default: SilverStripe\Security\MemberAuthenticator\Authenticator`
CMS Login Handling 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 2017-04-30 05:17:26 +02:00			`cms: SilverStripe\Security\MemberAuthenticator\CMSAuthenticator`

			`SilverStripe\Security\MemberAuthenticator\CMSSecurity:`
			`reauth_enabled: true`