Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
en:extensions:cloudfile:permission [2014/08/06 22:15] swarnat |
en:extensions:cloudfile:permission [2014/08/06 22:29] (current) swarnat |
||
|---|---|---|---|
| Line 9: | Line 9: | ||
| **Example** | **Example** | ||
| The path | The path | ||
| - | /main/sub/directory/ | + | **/main/sub/directory/** |
| will checked like this: | will checked like this: | ||
| - Did I have access to **/**, if not prevent complete access | - Did I have access to **/**, if not prevent complete access | ||
| Line 28: | Line 28: | ||
| /main/sub/directory/ | /main/sub/directory/ | ||
| will checked like this: | will checked like this: | ||
| - | - If there is a permission configuration for **/main/sub/directory/**. If yes, follow the rule. (deny or grant access) | + | - If there is a permission configuration for **/main/sub/directory/**. If yes, apply the rule. (deny or grant access) |
| - | - If there is a permission configuration for **/main/sub/**. If yes, follow the rule. (deny or grant access) | + | - If there is a permission configuration for **/main/sub/**. If yes, apply the rule. (deny or grant) |
| - | - If there is a permission configuration for **/main/**. If yes, follow the rule. (deny or grant access) | + | - If there is a permission configuration for **/main/**. If yes, apply the rule. (deny or grant) |
| - | - If there is a permission configuration for **/**. If yes, follow the rule. (deny or grant access) | + | - If there is a permission configuration for **/**. If yes, apply the rule. (deny or grant) |
| </WRAP> | </WRAP> | ||
| + | |||
| + | You will get the question, how you could access **/main/sub** if the access to **/** is denied | ||
| + | I solved this in a way you don't need to have denied access in mind if you create configurations. | ||
| + | |||
| + | <WRAP left round tip 100%> | ||
| + | **Example** | ||
| + | If the filesystem looks like: | ||
| + | <code> | ||
| + | a | ||
| + | ab | ||
| + | ac | ||
| + | acd | ||
| + | acda | ||
| + | ace | ||
| + | b | ||
| + | ba | ||
| + | </code> | ||
| + | And you **prohibit the access of /a , allow the access to /a/ac/acd and allow /b** for the user . | ||
| + | Then the user will see the following filesystem: | ||
| + | <code> | ||
| + | a | ||
| + | ac | ||
| + | acd | ||
| + | acda | ||
| + | b | ||
| + | ba | ||
| + | </code> | ||
| + | And no **/a/ab** or **/a/ac/acd**. | ||
| + | Also the user won't see any other content of the directories below **/a/ac/acd**. | ||
| + | |||
| + | The system will manage the directories to makes it possible to navigate from the root to the directory the user could access. But nothing else is visible. | ||
| + | </WRAP> | ||
| + | |||
| + | You could try this best if you setup the "filesystem" provider and try it in local filesystem. | ||
| + | |||
| + | I decide to implement the permission system in this way, because this system makes it easier to allow only single directories and prohibit access to all other directories. | ||
| + | Also it isn't more work if you want to allow almost all directories and only prevent access to single directories. | ||