tonyair/silverstripe-framework
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-framework synced 2024-10-22 12:05:37 +00:00
Code Issues Projects Releases Wiki Activity

DOCS Clarify different file access types

Browse Source 
[ci-skip]
This commit is contained in:
Ingo Schommer 2019-05-23 09:22:10 +12:00
parent 74c869f362
commit 1cb22b665d
1 changed files with 16 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
docs/en/02_Developer_Guides/14_Files/03_File_Security.md
View File

@ -32,19 +32,30 @@ Access restrictions:
Like all other objects in SilverStripe, permissions are generally controlled via `can*()` methods, Like all other objects in SilverStripe, permissions are generally controlled via `can*()` methods,
for example `canView()` (see [permissions](/developer_guides/security/permissions)). for example `canView()` (see [permissions](/developer_guides/security/permissions)).
The permission model defines the following actions:
* View: Access file metadata in the database
* Edit: Edit file metadata as well as replacing the file content
* Create: Create file metadata and upload file content
* Delete: Delete file metadata and the file content
* Download: Access the file content, but not the file metadata.
Usually treated the same as "View".
There's a few rules guiding their access, in descending order of priority: There's a few rules guiding their access, in descending order of priority:
* Published files can be viewed (downloaded) by anyone knowing the URL * Published and unprotected files can be downloaded by anyone knowing the URL.
* Access can determined by custom `can*()` method implementations on `File` They bypass any SilverStripe permission checks (served directly by the webserver).
* Access can be restricted by custom `can*()` method implementations on `File`
(through [extensions](/developer_guides/extending/extensions)). (through [extensions](/developer_guides/extending/extensions)).
This logic can overrule any further restrictions below.
* Users with "Full administrative rights" (`ADMIN` permission code) * Users with "Full administrative rights" (`ADMIN` permission code)
have view and edit access by default, regardless of further restrictions below. have view and edit access by default, regardless of further restrictions below.
* Users with "Edit any file" permissions (`FILE_EDIT_ALL` permission code) * Users with "Edit any file" permissions (`FILE_EDIT_ALL` permission code)
have edit access by default, regardless of further restrictions below. have edit access by default, regardless of further restrictions below.
* View or edit access can be restricted per file or folder through * View or edit access can be restricted per file or folder through
an inherited permissions model similar to page content (through [api:SilverStripe\Security\InheritedPermissionsExtension]). an inherited permissions model similar to page content (through [api:SilverStripe\Security\InheritedPermissionsExtension]).
There are four types: "Inherit from parent" (default), "Anyone", "Logged-in users", There are four types: "Inherit from parent" (default), "Anyone", "Logged-in users", or "Only these groups".
or "Only these groups".
* Protected files (incl. draft files) allow view/edit access when `File::$non_live_permissions` is satisfied. * Protected files (incl. draft files) allow view/edit access when `File::$non_live_permissions` is satisfied.
By default, that's configured for anyone with access to any CMS section, or By default, that's configured for anyone with access to any CMS section, or
the ability to "view draft content". the ability to "view draft content".
@ -65,7 +76,7 @@ further restrictions in your project.
When implenting your own `canView()` logic through [extensions](/developer_guides/extending/extensions), When implenting your own `canView()` logic through [extensions](/developer_guides/extending/extensions),
existing unprotected files are not retroactively moved to the protected asset store. existing unprotected files are not retroactively moved to the protected asset store.
While those new permissions are honoured in the CMS, protected files through custom `canView()` While those new permissions are honoured in the CMS, protected files through custom `canView()`
can still be downloaded through a public URL until they a `write()` operation is triggered on them. can still be downloaded through a public URL until a `write()` operation is triggered on them.
</div> </div>
## Asset stores ## Asset stores