* First cut * Temporarily disable composer.json for netlify build * POC * New recursive directory query, various refinements * Fix flexbox * new styled components plugin * Apply frontmatter delimiters * Mobile styles, animation * Search * Redesign, clean up * Nuke the cache, try again * fix file casing * Remove production env file * ID headers * Move app to new repo * Add frontmatter universally * Hide children changelogs * Add how to title * New callout tags * Revert inline code block change * Replace note callouts * Fix icons * Repalce images * Fix icon * Fix image links * Use proper SQL icon
1.9 KiB
title | summary | icon |
---|---|---|
Model-Level Permissions | Reduce risk by securing models. | lock |
Model-Level Permissions
Models can be modified in a variety of controllers and user interfaces, all of which can implement their own security checks. Often it makes sense to centralize those checks on the model, regardless of the used controller.
The API provides four methods for this purpose: canEdit()
, canCreate()
, canView()
and canDelete()
.
Since they're PHP methods, they can contain arbitrary logic matching your own requirements. They can optionally receive
a $member
argument, and default to the currently logged in member (through Security::getCurrentUser()
).
[notice]
By default, all DataObject
subclasses can only be edited, created and viewed by users with the 'ADMIN' permission
code.
[/notice]
use SilverStripe\Security\Permission;
use SilverStripe\ORM\DataObject;
class MyDataObject extends DataObject
{
public function canView($member = null)
{
return Permission::check('CMS_ACCESS_CMSMain', 'any', $member);
}
public function canEdit($member = null)
{
return Permission::check('CMS_ACCESS_CMSMain', 'any', $member);
}
public function canDelete($member = null)
{
return Permission::check('CMS_ACCESS_CMSMain', 'any', $member);
}
public function canCreate($member = null, $context = [])
{
return Permission::check('CMS_ACCESS_CMSMain', 'any', $member);
}
}
[alert]
These checks are not enforced on low-level ORM operations such as write()
or delete()
, but rather rely on being
checked in the invoking code. The CMS default sections as well as custom interfaces like ModelAdmin or
GridField already enforce these permissions.
[/alert]