We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 46279
    • 3 Posts
    Hi guys,

    I'm new to modx but the client's requirement is to use it for the next project.
    What we're doing is displaying on web user accounts from the REST (java) server.

    Basically communication is simple but my question is with login - is there a way (plugin?) to modify login process so we're logging in via API rather than local DB? (I mean we can still have users in DB but the login and pass is somewhere else) Or does it require core changes? And if yes how difficult that would be?

    R.
      • 28042 ☆ A M B ☆
      • 24,524 Posts
      If your API returns values that MODX can use, you don't need users in MODX at all. It's all in the SESSION. So login via your API, and use the return to set the SESSION values MODX needs to know that the user is logged in to the "web" context and belongs to a group that corresponds to the resource group you're protecting your pages with.

      The API doesn't have to return those specific values, just returning "success" would be enough to let you set the appropriate SESSION values.

      Of course, this would mean that all user management and any user data you want to display would have to come from your API rather than using the MODX/xPDO API. But it would have the tremendous advantage of having all of your user management in one place.
        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
        • 46279
        • 3 Posts
        Quote from: sottwell at Jan 19, 2014, 09:58 PM
        If your API returns values that MODX can use, you don't need users in MODX at all. It's all in the SESSION. So login via your API, and use the return to set the SESSION values MODX needs to know that the user is logged in to the "web" context and belongs to a group that corresponds to the resource group you're protecting your pages with.

        Ok so what you're saying is that it's possible to write a plugin / page with login functionality, login to REST server, receive response with "logged in" and authorisation key, and write it easily in MODX session pretending that it's internal MODX login (all permissions etc)?
        If yes I guess there's a lot of work saved, all I'd need to have other than standard functionality is save auth key for future API requests somewhere in session for pages like user profile.

        Now my question is - how easy is to modify MODx functionality? I mean in terms of user profile for instance, if I'd have to modify and rather than requesting DB it'd request API with session key - again would I have to write something separately or is there simple way of modifying functionality (like overwrite default helper/module/controller or sth)?
          • 28042 ☆ A M B ☆
          • 24,524 Posts
          I would say you'd be better off writing your own profile code and using your remote system's API. The code for MODX uses the MODX/xPDO API, which would have no relevance to your system. I'm saying this from experience, I've worked on a site that had its own user management with something like 30,000 registered users, but the users were actually created using SalesForce. It wasn't pretty.
            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
            Logging a user in in code is relatively simple. It's up to you to qualify the user, then just do something like this (assuming that the user in in the modx_users table):

                $usr = $modx->getObject('modUser', $criterion);
                $modx->user =& $usr;
                $modx->getUser();
                /* $contexts = $modx->getOption('sbsContexts', $sp, $modx->context->get('key'));
                $contexts = explode(',', $contexts); */
                $contexts=array('web');
                /* no auto login to 'mgr' context */
                if (isset($contexts['mgr'])) {
                    unset ($contexts['mgr']);
                }
                foreach ($contexts as $ctx) {
                    $ctx = trim($ctx);
                    if (!empty ($ctx)) {
                        $modx->user->addSessionContext($ctx);
                    }
                }
                $modx->sendRedirect($url);


            You don't even need Login or a plugin. The code above could be in a snippet. The only issue is making it secure.

            Storing information in the user profile is also very simple, though the user can see their information if they have access to the Manager. You can store it in an unused profile field or in the profile's 'extended' field, but a better option is probably these two fields of the user object:

            remote_key  (string)
            remote_data  (json)
            


            In that case, you woudn't even need to get the User Profile.
              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
              The problem with using both MODX and a remote user management system is that you have to keep the two synchronized. It's much easier to use one or the other for managing your users, using an API of some kind to connect whichever system you're not using for the user management.

              The system I was working with had user registration passed off to SalesForce, which every few minutes wrote a file to the MODx server, where a cron job opened the file every half hour or so and used the data to create users directly in the database, then archiving the file. Any action that needed validation from the SalesForce database used SOAP connections to fetch the data. All the MODx system did was validate login for protected pages, so it wasn't really necessary at all.

              MODX provides very nice and easy ways to manage MODX users, so it may all boil down to which of your two systems has the better user management system. But it really should be one or the other.
                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
                • 46279
                • 3 Posts
                Thanks a lot guys for quick response. That was my initial thought that despite the requirement using CMS on full API functionality is just pointless and will double work rather than speed it up. So the decision will go most likely with custom development smiley