tonyair/silverstripe-framework
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-framework synced 2024-09-30 13:19:11 +02:00
Code Issues Projects Releases Wiki Activity

DOCS Fix issue with bullets and backticks thinking they are code blocks

Browse Source 
Thanks to @stojg for reporting.
This commit is contained in:
Cam Findlay 2015-05-23 17:58:51 +12:00
parent cc6a2ef757
commit 15ea4aa54c
1 changed files with 14 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
docs/en/02_Developer_Guides/09_Security/03_Authentication.md
View File

@ -7,35 +7,29 @@ By default, SilverStripe provides a `[api:MemberAuthenticator]` class which hook
authentication system.
The main login system uses these controllers to handle the various security requests:
* `[api:Security]` Which is the controller which handles most front-end security requests, including
Logging in, logging out, resetting password, or changing password. This class also provides an interface
to allow configured `[api:Authenticator]` classes to each display a custom login form.
* `[api:CMSSecurity]` Which is the controller which handles security requests within the CMS, and allows
users to re-login without leaving the CMS.
`[api:Security]` - Which is the controller which handles most front-end security requests, including logging in, logging out, resetting password, or changing password. This class also provides an interface to allow configured `[api:Authenticator]` classes to each display a custom login form.
`[api:CMSSecurity]` - Which is the controller which handles security requests within the CMS, and allows users to re-login without leaving the CMS.
## Member Authentication
The default member authentication system is implemented in the following classes:
* `[api:MemberAuthenticator]` Which is the default member authentication implementation. This uses the email
and password stored internally for each member to authenticate them.
* `[api:MemberLoginForm]` Is the default form used by `MemberAuthenticator`, and is displayed on the public site
at the url `Security/login` by default.
* `[api:CMSMemberLoginForm]` Is the secondary form used by `MemberAuthenticator`, and will be displayed to the
user within the CMS any time their session expires or they are logged out via an action. This form is
presented via a popup dialog, and can be used to re-authenticate that user automatically without them having
to lose their workspace. E.g. if editing a form, the user can login and continue to publish their content.
`[api:MemberAuthenticator]` - Which is the default member authentication implementation. This uses the email and password stored internally for each member to authenticate them.
`[api:MemberLoginForm]` - Is the default form used by `MemberAuthenticator`, and is displayed on the public site at the url `Security/login` by default.
`[api:CMSMemberLoginForm]` - Is the secondary form used by `MemberAuthenticator`, and will be displayed to the user within the CMS any time their session expires or they are logged out via an action. This form is presented via a popup dialog, and can be used to re-authenticate that user automatically without them having to lose their workspace. E.g. if editing a form, the user can login and continue to publish their content.
## Custom Authentication
Additional authentication methods (oauth, etc) can be implemented by creating custom implementations of each of the
following base classes:
* `[api:Authenticator]` The base class for authentication systems. This class also acts as the factory
to generate various login forms for parts of the system. If an authenticator supports in-cms
reauthentication then it will be necessary to override the `supports_cms` and `get_cms_login_form` methods.
* `[api:LoginForm]` which is the base class for a login form which links to a specific authenticator. At the very
least, it will be necessary to implement a form class which provides a default login interface. If in-cms
re-authentication is desired, then a specialised subclass of this method may be necessary. For example, this form
could be extended to require confirmation of username as well as password.
`[api:Authenticator]` - The base class for authentication systems. This class also acts as the factory to generate various login forms for parts of the system. If an authenticator supports in-cms reauthentication then it will be necessary to override the `supports_cms` and `get_cms_login_form` methods.
`[api:LoginForm]` - which is the base class for a login form which links to a specific authenticator. At the very least, it will be necessary to implement a form class which provides a default login interface. If in-cms re-authentication is desired, then a specialised subclass of this method may be necessary. For example, this form could be extended to require confirmation of username as well as password.
## Default Admin