We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 51472
    • 4 Posts
    Please be gentle -- as you can see I am rather new here.

    I apologise for the length of the post, but it seems a complicated issue -- to me. wink

    The error I am experiencing is one I am unable to understand, or to find any aid about; here at MODX, or out there in Google land. It is pertaining to the Login extra. There are two other threads that probably relate to the same issue, neither of which have been resolved.

    http://forums.modx.com/thread/75184/intermittent-trouble-with-register-user-activation-links
    http://forums.modx.com/thread/98327/issues-aka---its-not-working

    The issue is that users are not activated on clicking the link in the email sent to them, but redirected on a 404. As with the guys above, everything else functions perfectly.

    First, the good news: I have managed to shed some new light on the matter, that hopefully will help us all.

    I have FURLs off, so it is clear in the email that the link directed to is live and published. The redirection turns out to be an after effect, not the primary issue.

    What happens is that on the initial use of that email an error occurs, but only after the response is recognised. The message printed to the screen is cryptic and on a clear white screen -- so most users will simply respond by clicking the link again. However, when they do they are still flagged as inactive, but now are also unexpected and unceremoniously sent to the Unauthorized page.

    Then the less wonderful news: that I still can't figure out what the matter is. I have NOT altered the package code in any way. I did so for debugging, but reverted the affected file back to the original again afterward.

    The message displayed to the user is:
    Fatal error: Call to protected method xPDOObject::_setRaw() from context 'LoginConfirmRegisterController' in /core/component/login/controllers/web/ConfirmRegister.php on line 63


    It is associated with two errors in the MODX logs:
    [2015-12-02 21:24:32] (ERROR @ /connectors/index.php) Could not get table class for class: modAccess
    [2015-12-02 21:24:32] (ERROR @ /connectors/index.php) Could not get table name for class: modAccess
    [2015-12-02 21:24:32] (ERROR @ /connectors/index.php) Error 42000 executing statement: 
    Array
    (
        [0] => 42000
        [1] => 1064
        [2] => You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AS `modAccess` WHERE `modAccess`.`principal` = 2' at line 1
    )
    
    [2015-12-02 21:24:32] (ERROR @ /connectors/index.php) Could not get table class for class: modAccess
    [2015-12-02 21:24:32] (ERROR @ /connectors/index.php) Could not get table name for class: modAccess
    [2015-12-02 21:24:32] (ERROR @ /connectors/index.php) Error 42000 executing statement: 
    Array
    (
        [0] => 42000
        [1] => 1064
        [2] => You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AS `modAccess` WHERE `modAccess`.`principal` = 3' at line 1
    )


    To add insult to injury, the affected line follows the code that should actually activate the user, although I know that things are not necessarily structured in that way at deeper levels.
            61.    /* activate user */
            62.   $this->user->set('active',1);
            63.   $this->user->_setRaw('cachepwd',''); <= THIS IS THE LINE CAUSING THE TROUBLE.
            
    

    I am using .htaccess at the root level, but I have not altered the script in anyway. I am not using any funny stuff in MySQL, or any other aspect of the server and installation either. I have reached the end of my current insight, and I am unable to dedicate enough time to understand the xPDO and MODX source any better. I do hope some good samaritan is able to help.

    Thanks in advance.

    This question has been answered by multiple community members. See the first response.

    [ed. note: burningshade last edited this post 8 years, 4 months ago.]
    • discuss.answer
      • 3749
      • 24,544 Posts
      That call to _setRaw() was added in the latest version of the Login package (and my code editor flags is as a PHP error).

      It's actually on line 58 of the /core/component/login/controllers/web/ConfirmRegister.php file.

      I think it will solve your problem if you change it to this:

      $this->user->set('cachepwd','');


      BTW, you might look at the Subscribe extra, which wraps the whole registration process for you and provides some extra options.
        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
        • 51472
        • 4 Posts
        Thanks BobRay!

        You are a star -- as usual. You have already helped me no end in learning the ropes, through your past writings. I owe you dude!

        The suggested change did the job perfectly.

        Being an inveterate minimalist, I invariably shy away from installing anything that looks heavier than I suspect I need, but I will look into SubscribeMe ( please correct me if that is not what you intended ).

        Thanks again, and all the best.
          • 3749
          • 24,544 Posts
          No, not SubscribeMe (that's something else and is no longer supported). I meant Subscribe. In addition to simplifying and extending the registration process, I think Subscribe is more secure than Resister, since Register has critical user information encoded in the link it sends.

          Subscribe also works nicely with Notify, which lets you send emails and updates to selected groups of users with the option of using Mandrill for the send so your server is not burdened by the process.
            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
          • discuss.answer
            • 51472
            • 4 Posts
            Thanks again!

            I keep looking in the rtfm docs for extras, instead of inside the MODX manager. I am learning though, and I have found your package.
              • 10378
              • 375 Posts
              Quote from: BobRay at Dec 03, 2015, 08:51 PM
              That call to _setRaw() was added in the latest version of the Login package (and my code editor flags is as a PHP error).

              It's actually on line 58 of the /core/component/login/controllers/web/ConfirmRegister.php file.

              I think it will solve your problem if you change it to this:

              $this->user->set('cachepwd','');


              BTW, you might look at the Subscribe extra, which wraps the whole registration process for you and provides some extra options.

              Hi Bob,
              It was my pull request which included the above change to _setRaw.
              The problem with your suggestion is, that the chachepwd field isnt cleared with your call.

              Il'l provide a fix for my previous pull request tomorrow.
                Freelancer @bitego http://www.bitego.com
                ---
                GoodNews - one of the most advanced and integrated Group Mailer premium add-ons for MODX Revolution!
                More infos here: http://www.bitego.com/extras/goodnews/
                • 3749
                • 24,544 Posts
                Hi Gagetto.

                I saw your PR after I posted.

                I can see why my solution doesn't work. I think the problem is in the set() method of the modUser class file.

                I think it needs something like this:

                if ( (!empty($k)) && in_array($k, array('password', 'cachepwd')) && $this->xpdo->getService('hashing', 'hashing.modHashing')) {


                I don't think there's any reason to create a hash value for an empty password or cachepwd. [ed. note: BobRay last edited this post 8 years, 4 months ago.]
                  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
                  • 10378
                  • 375 Posts
                  Quote from: BobRay at Dec 05, 2015, 06:45 AM
                  I can see why my solution doesn't work. I think the problem is in the set() method of the modUser class file.

                  I think it needs something like this:

                  if ( (!empty($k)) && in_array($k, array('password', 'cachepwd')) && $this->xpdo->getService('hashing', 'hashing.modHashing')) {


                  I don't think there's any reason to create a hash value for an empty password or cachepwd.

                  I've already written a real fix which we will need to use until the problem is fixed in the MODX core.
                  Just preparing the pull request for Login repo on GIT:

                      /**
                       * Helper method to empty users cachepwd field.
                       *
                       * @access public
                       * @param integer $userID
                       * @return void
                       */
                      public function emptyCachePwd($userID) {
                          $table = $this->modx->getTableName('modUser');
                          $sql = "UPDATE {$table} SET `cachepwd`='' WHERE id=".$userID;
                          $stmt = $this->modx->prepare($sql);
                          $stmt->execute();
                      }
                  


                  and instead of using the set method:

                          ....
                          /* activate user */
                          $this->user->set('active',1);
                          
                          if (!$this->user->save()) {
                              $this->modx->log(modX::LOG_LEVEL_ERROR,'[Register] Could not save activated user: '.$this->user->get('username'));
                              return '';
                          }
                  
                          /* Empty the users cachepwd after user object is saved */
                          $this->login->emptyCachePwd($this->user->get('id'));
                          ....
                  

                    Freelancer @bitego http://www.bitego.com
                    ---
                    GoodNews - one of the most advanced and integrated Group Mailer premium add-ons for MODX Revolution!
                    More infos here: http://www.bitego.com/extras/goodnews/
                    • 10378
                    • 375 Posts
                    Pull request with a fix is online: https://github.com/modxcms/Login/pull/55

                    The problem is, the original: $this->user->set('cachepwd',''); doesn't work as this generates a hash of an empty value and the cachepwd field isn't emptied.
                    As @BobRay already stated, this is a problem in the MODX core and needs to be fixed.

                    My first fix (previous PR), using the _setRaw method also doesn't work in some cases, as this method is protected.
                      Freelancer @bitego http://www.bitego.com
                      ---
                      GoodNews - one of the most advanced and integrated Group Mailer premium add-ons for MODX Revolution!
                      More infos here: http://www.bitego.com/extras/goodnews/
                      • 3749
                      • 24,544 Posts
                      That looks good to me. smiley
                        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