A potential account hijacking may happen if an attacker has physical access to
victim's computer to perform session fixation. Also possible if the targeted application contains an XSS vulnerability.
Requires the victim to click the password reset link sent to their email.
If all the above happens, attackers may reset the password before the actual user does that.
In scenarios where:
- No member is logged in
- An 'AutoLoginHash' is provided via the 't' (token) query param
- The token isn't valid (determined by Member::validateAutoLoginToken())
The message which is intended to be returned to the end-user via $Content
in the template, is mistakenly double nested in ['Content' => ['Content' => 'Message']]
this leads to "The method forTemplate() doesn't exist on ArrayData" errors.
See - https://github.com/silverstripe/silverstripe-framework/issues/7866
- Moved the Authenticators from statics to normal
- Moved MemberLoginForm methods to the getFormFields as they make more sense there
- Did some spring-cleaning on the LostPasswordHandler
- Removed the BuildResponse from ChangePasswordHandler after spring cleaning
- Move the success and message to a validationresult
- Fix tests for validationresult return
- We need to clear the session in Test logOut method
- Rename to MemberAuthenticator and CMSMemberAuthenticator for consistency.
- Unify all to getCurrentUser on Security
- ChangePasswordHandler removed from Security
- Update SapphireTest for CMS login/logout
- Get the Member ID correctly, if it's an object.
- Only enable "remember me" when it's allowed.
- Add flag to disable password logging
- Remove Subsites coupling, give it an extension hook to disable itself
- Change cascadeLogInTo to cascadeInTo for the logout method logic naming
- Docblocks
- Basicauth config
Repairing tests and regressions
Consistently use `Security::getCurrentUser()` and `Security::setCurrentUser()`
Fix for the logout handler to properly logout, some minor wording updates
Remove the login hashes for the member when logging out.
BasicAuth to use `HTTPRequest`
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.