We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 21767
    • 44 Posts
    I have member-only pages but I want that all anonymous users may read the title of the resources within a destined snippet call, because I am outputing a list of member-only-sides with role of membership status or rank (no member, member, super user, and so on).

    But when I correctly understand the securtiy concept of Revo then forbidden resources wouldn’t exist at all for such users. Thus, it is also impossible for them to find a title of a forbidden resource. Correct?

    What can I do instead?
    Is it possible, for examble, to code a interim modx-dispensation of the security within the destined snippet?
      • 21767
      • 44 Posts
      Another idea:

      Create a context like "listGroups"
      Create context ACLs for anonymous users (if possible?)
      Login into context (if possible without account?)
      Make your Requests
      Logout of context
        • 22019
        • 390 Posts
        I’m not sure I’m understanding you correctly (and I haven’t tried this myself, but I’m fairly sure I’ve seen it elsewhere on the forum) but my understanding is that you would show/hide the sidebar in a conditional chunk (eg using the If package, or directly written in code).

        admins see $adminChunk
        superusers see $superChunk
        etc

        So the resource itself is visible to all, but the template outputs different things on the rendered page depending on the credentials of the user accessing it. A really simple example is the login example on RTFM, which outputs different things depending on whether you’re logged in or not - the principle’s the same, you’re just extending it....
          Writer > E-consultant > MODx developer || Salesforce || modx 2.x || PHP 5.2.13 || MySQL client 5.0.86
          • 21767
          • 44 Posts
          Thanks odecls, sadly that’s not I am searching for.

          It is no conditional problem. I need the title of a forbidden resource. I need it always, it’s the same which user.
          And Login is using
          $modx->user->isAuthenticated($modx->context->get('key'));

          This is also asking if you are logged in to the ’web’ context.
          But we are learning.
            • 18373 ☆ A M B ☆
            • 3,141 Posts
            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.
              Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

              Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
              • 22303 MODX Staff
              • 10,725 Posts
              Quote from: Mark at Sep 24, 2010, 08:08 PM

              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.
              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).

              Example of code that respects ACLs:
              <?php
              $resources = $modx->getCollection('modResource', array('published' => true));
              // do stuff with the published modResource objects you have access to
              ?>


              Example of code that works around ACLs:
              <?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
                  }
              }
              ?>
                • 18373 ☆ A M B ☆
                • 3,141 Posts
                Revolution (or rather: the way it has been coded) can’t seem to stop surprising me for a minute... We really owe you guys big time.

                Thanks for the clear explanation there.




                Am just thinking about this problem.

                There’s a "load" and "view" permission which are used in resource ACLs (of course, there are more, but I think these are the ones that have to do with front-end visibility, perhaps "list" also..).

                When an ACL allows a user to load the object, they will get a 403 error instead of 404 saying it does not exist. So that means "load" allows them to see that the resource exists, whereas "view" will make them able of seeing the actual parsed template..

                Not tested this, but based on the above logic (and assuming it being "visible" means you can access it with MODx objects, as getCollection takes those acl’s into consideration), shouldn’t you be able to give the anonymous user group the "load" acl, making it visible to a snippet using the modx objects?

                (After that, you could use a resource group to use in conjunction with the load permission to limit it to certain resources.)

                Don’t forget that while testing security, to use a different browser (not just a different tab or window, but use IE while being logged in on the manager in FF for example), as you’ll be viewing the site with your manager user permissions then.

                And flush when you made a change. wink
                  Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

                  Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
                  • 21767
                  • 44 Posts
                  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 I get the hang of such code in the manager source, now. The manager has exactly the same problem sometimes, when it has to work without ACLs, too.

                  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. In this case, you would be able to code the whole manager application in modx classes and the welcome side effect is that many of that functions are also interesting for front end programmers.

                  About anonymous user:

                  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’. 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.
                    • 18373 ☆ A M B ☆
                    • 3,141 Posts
                    Quote from: norblenn at Sep 25, 2010, 09:06 AM

                    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.
                    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".

                    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’.

                    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.
                    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.

                    The anonymous group is intended for those without a login (or with one but not logged in). I don’t want to change acls for these users.... how would it be possible to distinguish who gets assigned what?

                    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.



                    Did you try setting load permission on Anonymous?
                      Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

                      Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
                      • 21767
                      • 44 Posts
                      Is this
                      <?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
                      ?>

                      the correct equivalent of
                      <?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'], );
                          }
                      }
                      ?>

                      to continue with
                      //<?php
                      foreach ($colUG as $grp) {
                        foreach ($docs as $doc) {
                          if ( $doc->get('longtitle') == $grp->get('name') ) {
                      //...
                      

                      ?