We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 19004
    • 33 Posts
    Here is the scenario I’m running into with webloginpe:

    1. I log into the system as a user (belongs to group "x")
    2. I click the "logout" button. This appears to work
    3. I log in as another user (belongs to group "y")

    When I do this, it appears to be retaining the group credentials of user #1 and applying to user #2. I can’t tell if this is something to do with the logout/login mechanism of webloginpe or if it is an issue with modx itself (running 9.6.1).

    Here is the code that I’m using to check the group credentials:

    // Config
    $member_top = 4;
    $default_home = 22;
    
    // Get list of user groups, grab first one
    $grps = $modx->getUserDocGroups(true);
    $group = "";
    if (count($grps)) {
         $group = $grps[0];
    }
    
    // If user belongs to a group, send them to their home page (return id)
    if ($group) {
         $kids = $modx->getDocumentChildren($member_top,1,'0','id, longtitle');
         foreach($kids as $kid) {
             // Hack: use "longtitle" to identify the "home page" for each group
             if ($kid['longtitle'] == $group) {
                  return $kid['id'];
             }
         }
    }
    
    // Not logged in or have no home page - send to login page
    return $default_home;


    getUserDocGroups does not appear to be retrieving the correct user’s information for some reason, gets stuck on the first user to log in, even though the page that is calling the snippet is set to non-cacheable.

    Any ideas?
      • 19004
      • 33 Posts
      No ideas?
        • 25979
        • 178 Posts
        Quote from: mediced at May 05, 2008, 04:40 PM

        No ideas?

        Don’t know, but what about cache?
          //Why use windows since there is a door?//
          • 19004
          • 33 Posts
          It does seem to be a caching issue, but the issue is with modx, not the browser. It recognizes the user’s cookie just fine, it just attributes the wrong permissions to that user (at least when called through the api). I was hoping somebody had come across this problem before. I have multiple installations of modx and webloginpe and they all have this same issue.

          If there was some sort of way to auto-clear the cache via the api, that might help but I have no clue how to do that.
            • 25979
            • 178 Posts
            Quote from: mediced at May 05, 2008, 05:14 PM

            It does seem to be a caching issue, but the issue is with modx, not the browser. It recognizes the user’s cookie just fine, it just attributes the wrong permissions to that user (at least when called through the api). I was hoping somebody had come across this problem before. I have multiple installations of modx and webloginpe and they all have this same issue.

            If there was some sort of way to auto-clear the cache via the api, that might help but I have no clue how to do that.

            hmm, I got a couple of heavy modified WebLoginPE installations but never got this problem. Maybe there is sth wrong with your installation files.
            I
              //Why use windows since there is a door?//
              • 19004
              • 33 Posts
              I’ve actually discovered the issue, if not the solution:

              The problem is that this portion of my code is not executing as you would expect:
              if ($type) {
                   $kids = $modx->getDocumentChildren($member_top,1,'0','id,longtitle');
                   foreach($kids as $kid) {
                       if ($kid['longtitle'] == $type) {
                            return $kid['id'];
                       }
                   }
              }


              getDocumentChildren is only returning the first child of $member_top. No matter what I do, all of the other ones are ignored. Each child page belongs to a separate doc group, and the main page itself belongs to all doc groups.

              In theory, getDocumentChildren should return the list of children that the current user has permissions for, or simply all of the children. In this case I am getting neither. Strangely enough, the getUserDocGroups call is working fine now.