We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 34162
    • 1 Posts
    Hey, guys, I have yet another dumb question--

    Couldn’t the processors/login.processor.inc.php be recreated as a plugin?

    I notice it already has event hooks before and after the login processor and it reincludes so much code from the main manager/index.php file it almost seems like a hack.

    Just thinking if that was done it might go quite a ways towards letting us authenticate using other mechanisms, too, instead of just hitting manager_users.

    Good idea/bad idea?
      • 32963
      • 1,732 Posts
      Hmmm,

      True! We could make it into a plugin but the problem here is what is someone accidentally disbabled it? If that happends then they would not be able to log back into the manager.

      The login processor can be bypassed by using the existing Manager Login events such as OnManagerAuthentification, OnBeforeManagerLogin, etc.

      it reincludes so much code from the main manager/index.php file it almost seems like a hack.

      We might need to remove duplicate functions or processes.
        xWisdom
        www.xwisdomhtml.com
        The fear of the Lord is the beginning of wisdom:
        MODx Co-Founder - Create and do more with less.
      • What about then making it very difficult to disable certain "key" plugins without introducing a replacement / equivalent, possibly by adding another column that denotes if a plugin is a replacement to a core plugin. That way the only way someone could disable something like a manager login plugin would be if another one had taken over. Otherwise, it’d be disabled.
          Ryan Thrash, MODX Co-Founder
          Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
          • 34162
          • 1 Posts
          In fact there were a lot of interest to use LDAP as an mean to authenticate user. With this feature in Modx it would make it easier for intranet type of application that would take advantage of a CMS.
            • 1764
            • 680 Posts
            In a related note. I’ve been working on an IMAP plugin for a while now. It works just fine in most cases but I’m runing into problems getting it to work through the frontend. The problem stems from the fact that when the imap_open function fails it returns a PHP error. In the login.processor.php file this is no problem because normal error control functions work just fine. However, if it’s used in a snippet the phpError handler takes over and there is no way to tell it to ignore errors. You can use stopOnNotice to tell it to ignore notices but there is no similar option for ignoring errors.

            I’ve tried PHP error handling, output buffering but nothing seems to work.

            So, I think the best solution would be to add a stopOnWarning and a stopOnError property to the error handling. It seems like this is something that we should have anyway. Or maybe the better solution would be to have the phpError function look at the normal PHP error_reporting values and respond accordingly. What do you think?
              • 34162
              • 1 Posts
              Adam: If the IMAP plugin works, can you toss me a copy?
                • 18397
                • 3,250 Posts
                Ditto.
                  • 1764
                  • 680 Posts
                  Quote from: infoclipper at Aug 31, 2005, 03:32 AM

                  Adam: If the IMAP plugin works, can you toss me a copy?

                  Ask and you shall recieve
                  http://modxcms.com/forums/index.php/topic,861.0.html