$modx->user->isAuthenticated($modx->context->get('key'));The Revolution classes that extend modAccessibleObject check permissions (load, save, remove) even when using it in your custom code. So it actually respects the ACLs. You can write code that bypasses security by not loading objects and working directly with the PDOStatements and result sets that are prepared by the xPDOCriteria/xPDOQuery APIs. The exceptions are running modX from CLI (when no session is available, security is not available, yet), or accessing the objects with a separate xPDO instance instead of a modX instance (the security is only checked when accessing it with modX; modX extends xPDO and adds the security layer to the data objects).
Hmmm... tried to fetch the list with a custom code using the Revo Objects (look at Bob’s website for some nice info on that)?
This is just a guess, but I expect something like getResources or Wayfinder checks the security acls, but using custom code would not (unless you tell it to).
I’ve also not tried this, but it is an interesting idea.
<?php
$resources = $modx->getCollection('modResource', array('published' => true));
// do stuff with the published modResource objects you have access to
?><?php
$stmt = $modx->newQuery('modResource', array('published' => true))->prepare();
if ($stmt && $stmt->execute()) {
while ($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
// do stuff with the raw result sets of all published modResource rows in the db here
}
}
?>
MODx is an extension of XPDo in the way that I see it... it offers shortcuts, or more easy to comprehend ways of doing the same... the MODx class would be "system coding".
About Jason’s code example:
I am not so enthusiastic, because I think that the front end application programmer shouldn’t use any system coding as avoidable.
But is that really clever? I prefer a model that allows all programming in modx classes. The modx class itself should be able to switch off the security layer.That is a suggestion I like, but in my opinion that’d need to be limited to only the call/function specifying it to not make it harder to *use* acls.
Another problem is the anonymous user. If you visit Manager-Security-Access Controls, then ’anonymous users’ looks like a user group, and many users actually may take the ’anonymous user’.If you mean users (accounts on MODx) may be assigned tot he Anonymous User group... that doesn’t show up in the dropdown box when selecting a group, so no.
But the anonymous user has id=0. It is always one instance in the back end. When you change any ACL for anonymous user, then you change it for all anonymous users.
I thought about it a lot of time and I have gotten another idea. I could create a dummy user. That dummy user would get extra context ACLs. And then, when I make my requests on forbidden resources, I login to that dummy user, and after that procedure I logout and login back to the former account if necessary. This should work for all such cases. But it is only a workaround.
<?php
//Example of code that respects ACLs:
$query = $modx->newQuery('modResource', array('parent' => 30, 'deleted' => false, 'published' => true));
$query->select($modx->getSelectColumns('modResource', 'modResource', '', array('id', 'longtitle')));
$docs = $modx->getCollection('modResource', $query);
// do stuff with the published modResource objects you have access to
?><?php
//Example of code that works around ACLs:
$query = $modx->newQuery('modResource', array('parent' => 30, 'deleted' => false, 'published' => true))->prepare();
$query->select($modx->getSelectColumns('modResource', 'modResource', '', array('id', 'longtitle')));
//$docs = $modx->getCollection('modResource', $query);
$docs = array();
if ($query && $query->execute()) {
while ($row = $query->fetch(PDO::FETCH_ASSOC)) {
// do stuff with the raw result sets of all published modResource rows in the db here
$docs[$row['name']] = array("longtitle"=>$row['longtitle'],
"id"=>$row['id'], );
}
}
?>//<?php
foreach ($colUG as $grp) {
foreach ($docs as $doc) {
if ( $doc->get('longtitle') == $grp->get('name') ) {
//...