We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 41874
    • 33 Posts
    i all,

    I'm using the Login addon, and got it up and running. I created a resource group and user group with Web context access and protected some members only pages.

    However, another user, in another group with manager access but not Web Access can login (but can't see the pages). This is frustrating because this user will be redirected to the protected pages on a successful login.

    A user without Web Access should not be able to login at the frontend right?

    Some details:

    Resource group: protect
    User groups:
    Protect
    - resource group : protect
    - context access : Web - member
    Another
    - context access : mgr - memer


    Thanks in advance!
    Huub
      I love flexibility
      • 3749
      • 24,544 Posts
      I'm not sure I understand what you're trying to do, but a user's group needs to have a *Context* Access ACL entry for the Web Context in order for that user to see pages in the Web context in the Resource tree in the Manager. There's really no way around that.
        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
        • 41874
        • 33 Posts
        Thanks for your time and reply!

        I have some Web users, which are only allowed to the Web, and some manager users, which are only allowed to the manager. I would like to deny this last group from frontend access, because they won't have any access to the restricted resource groups.

        I was expecting to manage hat by only give them ACL access to the manager context (they won't need the resources list).

        But they can login and then do nothing because they are not in the right resource group (which is good!). But I prefer deny at login.

        I hope this info will make you understand the problem.

        Huub
          I love flexibility
          • 28042 ☆ A M B ☆
          • 24,524 Posts
          As far as I can tell, logging in via the front-end Login form and snippet doesn't give the user "mgr" access at all. A manager user has to log in to the Manager via the manager login form. Unless a manager user is a "sudo" user, if I understand correctly, he'll be restricted (via his group's ACL) from viewing protected front-end pages like any other user.
            Studying MODX in the desert - http://sottwell.com
            Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
            Join the Slack Community - http://modx.org
            • 3749
            • 24,544 Posts
            I think I get it, though I don't understand why you'd want to show users resources in the Manager and let them edit them but hide those same resources from them in the front end.

            That said, there are several ways to handle the problem, none of them very convenient. I think any of these would work, but I'm not positive.

            1. You could put all the resources in a Resource Group and protect it with a Resource Group Access ACL entry with a context of 'web' that connects that Resource Group to a User Group they don't belong to. They could log in in the front end, but they wouldn't be able to see those resources. I'm not sure they would still show in the tree, but I think they would, though the users might not be able to edit them.

            2. You could add a snippet to the Template that forwarded users somewhere if they belong to the Manager-only user group.

            if ($modx->user->isMember('ManagerOnly')) {
                $modx->sendRedirect('url/of/some/page');
            
            }


            3. You could use a plugin connected to OnWebPagePrerender similar to the above.

            4. You could use a preHook for the front-end Login snippet that check the User Group membership and either denied the login (I think), or forwarded the user.

            I'm not sure which of these would prevent the Manager users from viewing the pages from the Manager. My guess is that #1, #2, and #3 would prevent them, and #4 would not.

            All this assumes that I understand what you're trying to do. wink
              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
              • 28042 ☆ A M B ☆
              • 24,524 Posts
              "they won't need the Resources list" - so apparently there won't be any editing going on. But that can be hidden in their group's ACL.
                Studying MODX in the desert - http://sottwell.com
                Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
                Join the Slack Community - http://modx.org
                • 3749
                • 24,544 Posts
                That would make #1 the best choice, except that it won't prevent them from logging in in the front end (though it won't do them any good).
                  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
                  • 41874
                  • 33 Posts
                  Thanks again, for joining this thread! I'll give a little twist to both your interpretations:

                  To be clear. I got 2 user groups (changed the names - according to the first post - to be clear):

                  1. Component1Admins This group has access to the manager and can manage entries in a specific Component1. So they dont manage resources, and don't need access to the 'web' context.
                  2. CustomFrontendAdmins This group has access to a custom made area (restricted by a resource group) to manage other entries.

                  The first group are like admins (manage multiple components), but without resource management. The 2nd group are just simple frontend users which need a simple interface.

                  Now the problem is that the first group could log-in to the frontend login form, and get access, while their ACL does not contain the 'web' access. They should not get access if I understand the permissions correct. The problem is that I would not give them access, to not give them make mistakenly access to some area's.

                  @susan, your right it doesn't give the user mgr access, but the user get `web` access, while it shouldn't. If run this code as postHook (of login form) the code will get into the if statement;
                  <?php
                  $user = $modx->getUser();
                  if ($user->hasSessionContext('web')) {
                      echo 'What?, the mgr user can get access to the web context? weird...';
                  }


                  @bob, thanks for the number of solutions, really inspires me to get to a solution, for example #2 as pre-/postHook for the Login script. Then the `Component1Admins` will be redirected to the manager instead of loggin in the frontend restricted pages.

                  Actually i'm interested in the following: does my problem occur if i would put the restricted pages in a separate context? Then I create these contexts:

                  • mgr This is the manager
                  • admin This is a restricted area in the frontend where some entries can be managed easily
                  • web The public website
                  Where for each context a parrallel user group (with the context ACL) is created. Then, if a User (in the mgr user group) logs in to the frontend admin, will he be denied?

                  Thanks again, for your time, help and efforts!
                    I love flexibility
                    • 3749
                    • 24,544 Posts
                    Putting them in a separate Context might work, but in my experience, adding front-end Contexts usually leads to a number of other problems and I don't do it unless there's no other way.

                    Your situation is unusual and I'm not sure I get it completely, but If your Component1Admins can log into the web context in the front end, they must have a Context Access ACL entry with a context of 'web' which it sounds like they don't need. If you take away their resource_tree permission, BTW, they shouldn't see the Resource tree at all.

                    Make sure you test the front-end access in another browser where you're not logged in to the Manager. If not you'll see all kinds of weird permission effects.

                    Make sure you flush permissions *and* flush all sessions after making any changes.
                      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
                      • 41874
                      • 33 Posts
                      Quote from: BobRay at Sep 13, 2013, 05:32 PM
                      Make sure you test the front-end access in another browser where you're not logged in to the Manager. If not you'll see all kinds of weird permission effects.

                      Make sure you flush permissions *and* flush all sessions after making any changes.
                      I did, thanks for the hints smiley

                      Quote from: BobRay at Sep 13, 2013, 05:32 PM
                      Putting them in a separate Context might work, but in my experience, adding front-end Contexts usually leads to a number of other problems and I don't do it unless there's no other way.
                      OK, so we won't use another context for this.
                      Quote from: BobRay at Sep 13, 2013, 05:32 PM

                      Your situation is unusual and I'm not sure I get it completely, but If your Component1Admins can log into the web context in the front end, they must have a Context Access ACL entry with a context of 'web' which it sounds like they don't need. If you take away their resource_tree permission, BTW, they shouldn't see the Resource tree at all.
                      You're right that they won't need it, therefore I removed it. And I thought then they couldn't login at the frontend, but they can.

                      I think I misused the context, because the Login snippet (frontend) just logs users in with the web (default) context. And the manager logs users in with the mgr context. Is this correct?

                      I `assumed` that users (which are in a group with `mgr` context but without `web` context) would be denied at Login snippet (frontend), but apparently this is not the case. [I assumed it because regular users - which are not in any group with mgr context - are denied at the manager login].

                      This will help as postHook for frontend login, to forward the users to the right login page:
                      <?php
                      // A whitelist of User Groups which may login at frontend.
                      $whitelistUserGroups = array("CustomFrontendAdmins1", "CustomFrontendAdmins2");
                      if ($modx->user->isMember($whitelistUserGroups, false) === false) {
                          $modx->sendRedirect('url/to/the/manager');
                      }

                      And off course the permissions will be configured correctly in the backend, so this is only to prevent a white screen for manager users loggin in to the frontend login screen.

                      The problem is, this postHook won't work, actually I don't have a user at all... look at the following code as postHook:
                      <?php
                      var_dump($modx->user->id);
                      var_dump($modx->user->getUserGroups());
                      exit();
                      // outputs: int(0) array(0) { } 

                      The user which is trying to log in is definitely part of a user group (with web context ACL).

                      Can you explain that?

                      Thanks a lot!
                        I love flexibility