Permissions in Front End

- 24,544 Posts
BobRay Reply #1, 16 years, 8 months ago

My reading of the Security stuff led me to another question about code execution in the front end. Just when I think I understand everything, I dig a little deeper and come up with questions I can’t answer.

I’m starting a new thread to keep the discussion on that topic.

We’ve established that:

A user group has a context access ACL that gives mgr context access and a policy without access_permissions
The same user group has another context access ACL that gives web context access *with* access_permissions.

Those users can’t access permissions in the Manager but can do so using a front-end tool?

I want to ask about the opposite condition (sort of).

What are the conditions under which plugin and snippet code in the front end that performs Manager actions (e.g. clearing the cache) *won’t* execute because of security settings?

If the web context is *not* protected via any web Context Access ACL entry, all the manager action code should execute in the front end for everyone, logged in or not, right?

Assuming that the web context *is* protected via at least one web Context Access ACL entry . . .

It seems logical that if the front-end user is logged in and doesn’t have the permissions via a web Context Access ACL entry in their user group, the code won’t execute. Is that right?

What about non-logged-in users? It would seem that the code wouldn’t execute for them unless another web Context Access ACL entry granted the permissions for the manager actions contained in the code to 9999 users. Is that correct?

Finally, how does the code know that the permission was denied so it can respond appropriately (or is there an automatic permission denied "alert" in the front end)?
Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting
- MODX Staff
- 10,725 Posts
opengeek Reply #2, 16 years, 8 months ago
Quote from: BobRay at Jan 24, 2010, 11:21 PM

What are the conditions under which plugin and snippet code in the front end that performs Manager actions (e.g. clearing the cache) *won’t* execute because of security settings?

If the web context is *not* protected via any web Context Access ACL entry, all the manager action code should execute in the front end for everyone, logged in or not, right?

Correct, that’s why the Administrator policy is attached to the Administrators group in both web and mgr by default. If no policies were attached to any Contexts, it would be the same as giving anonymous users full permissions on everything in the system.

Quote from: BobRay at Jan 24, 2010, 11:21 PM

Assuming that the web context *is* protected via at least one web Context Access ACL entry . . .

It seems logical that if the front-end user is logged in and doesn’t have the permissions via a web Context Access ACL entry in their user group, the code won’t execute. Is that right?

That’s correct.

Quote from: BobRay at Jan 24, 2010, 11:21 PM

What about non-logged-in users? It would seem that the code wouldn’t execute for them unless another web Context Access ACL entry granted the permissions for the manager actions contained in the code to 9999 users. Is that correct?

anonymous users would not be able to execute anything unless a Context Access ACL entry a policy was attached to the special anonymous User Group. Any user accessing a Context that is not logged in to that Context is considered a Member of this anonymous User Group. All anonymous permissions must be set using the Member role or an equivalent with an Authority of 9999.

Quote from: BobRay at Jan 24, 2010, 11:21 PM

Finally, how does the code know that the permission was denied so it can respond appropriately (or is there an automatic permission denied "alert" in the front end)?

This depends on the nature of that code. If you are invoking core processors, these automatically check the appropriate permissions.
```
<?php
$result = $modx->executeProcessor(array(
    'location' => 'system'
    ,'action' => 'clearcache'
));
if (is_array($result)) {
    /* the result from the executeProcessor is an array of the following structure, e.g. if permission was denied:

Array
(
    [success] => 
    [message] => permission_denied
    [total] => 0
    [errors] => Array
        (
        )

    [object] => Array
        (
        )

)

    */
    if (!$result['success']) return $result['message'];
    // Now do whatever, maybe redirect or display a success message/chunk
    return $modx->getChunk('successChunk');
} else {
    // the processor was not successfully executed, record an error in the log
    $modx->log(modX::LOG_LEVEL_ERROR, "Error executing the processor");
}
?>
```
However, custom processors or snippet code can check permissions using the modX::hasPermission() method. Here are a couple of examples:
```
<?php
if (!$modx->hasPermission('foo')) $modx->sendUnathorized();
// code which executes only if 'foo' permission is granted goes here...
?>
```
```
<?php
if (!$modx->hasPermission(array('foo' => true, 'bar' => true))) $modx->sendUnathorized();
// code which executes only if both 'foo' and 'bar' permissions are granted goes here...
?>
```
Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek