mirror of
https://github.com/silverstripe/silverstripe-framework
synced 2024-09-16 14:36:26 +02:00
fdbd899766
- Remaining Developer Guides and Upgrading - SilverStripe in a namespace or api has not been change - To keep PRs easier no formatting was changed Update merge conflics with two files Update Silverstripe Ltd, Silverstripe Cloud and Silverstripe CMS Silverstripe CMS Ltd > Silverstripe Ltd Silverstripe CMS Platform > Silverstripe Cloud Silverstripe CMS Framework > Silverstripe CMS Resolve merge conflict Remove Framework from Silverstripe CMS Framework - 3 files Change SilverStripe CMS to Silverstripe CMS
67 lines
2.6 KiB
Markdown
67 lines
2.6 KiB
Markdown
---
|
|
title: Access Control
|
|
summary: Restrict CMS access to specific groups of users
|
|
icon: user-lock
|
|
---
|
|
# Access Control and Page Security
|
|
|
|
There is a fairly comprehensive security mechanism in place for Silverstripe CMS. If you want to add premium content to your
|
|
site you have to figure this stuff out, and it's not entirely obvious.
|
|
|
|
## Ways to restrict access
|
|
|
|
There are a number of ways to restrict access in Silverstripe CMS. In the security tab in the CMS you can create groups
|
|
that have access to certain parts. The options can be found on the [permissions](/developer_guides/security/permissions) documentation.
|
|
|
|
Once you have groups, you can set access for each page for a particular group. This can be:
|
|
* anyone;
|
|
* any person who is logged in;
|
|
* a specific group.
|
|
|
|
It is unclear how this works for data-objects that are not pages.
|
|
|
|
## The Security Groups in Silverstripe CMS
|
|
|
|
In the security tab you can make groups for security. The way this was intended was as follows (this may be a counter
|
|
intuitive):
|
|
|
|
* employees
|
|
* marketing
|
|
* marketing executive
|
|
|
|
Thus, the further up the hierarchy you go the MORE privileges you can get. Similarly, you could have:
|
|
|
|
* members
|
|
* coordinators
|
|
* admins
|
|
|
|
Where members have some privileges, coordinators slightly more and administrators the most; having each group inheriting
|
|
privileges from its parent group.
|
|
|
|
## Permission checking is at class level
|
|
|
|
Silverstripe CMS provides a security mechanism via the *Permission::check* method (see [LeftAndMain](api:SilverStripe\Admin\LeftAndMain) for examples on how
|
|
the admin screens work).
|
|
|
|
(next step -- go from *Permission::checkMember*...)
|
|
|
|
### Nuts and bolts -- figuring it out
|
|
|
|
Here are my notes trying to figure this stuff out. Not really useful unless you're VERY interested in how exactly SS
|
|
works.
|
|
|
|
|
|
### Loading the admin page: looking at security
|
|
|
|
If you go to [your site]/admin *Director.php* maps the 'admin' URL request through a [Director](api:SilverStripe\Control\Director) rule to the
|
|
[CMSMain](api:SilverStripe\CMS\Controllers\CMSMain) controller (see [CMSMain](api:SilverStripe\CMS\Controllers\CMSMain), with no arguments).
|
|
|
|
*CMSMain.init()* calls its parent which, of all things is called [LeftAndMain](api:SilverStripe\Admin\LeftAndMain). It's in [LeftAndMain](api:SilverStripe\Admin\LeftAndMain) that the
|
|
important security checks are made by calling *Permission::check*.
|
|
|
|
[Security::permissionFailure()](api:SilverStripe\Security\Security::permissionFailure()) is the next utility function you can use to redirect to the login form.
|
|
|
|
### Customizing Access Checks in CMS Classes
|
|
|
|
see [LeftAndMain](api:SilverStripe\Admin\LeftAndMain)
|