We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 3749
    • 24,544 Posts
    Did you try a plugin tied to OnBeforeWebLogin? I don't think it will work, but worth a shot.

    Worst case, you could modify the Login snippet code, adding this at the top of the part that processes the form :

    if (is_numeric($_POST['userName'])) {
            $_POST['userName'] = 'u' . $_POST['userName'];
    }



    ------------------------------------------------------------------------------------------
    PLEASE, PLEASE specify the version of MODX you are using.
    MODX info for everyone: http://bobsguides.com/modx.html [ed. note: BobRay last edited this post 14 years, 1 month 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
      • 28042 ☆ A M B ☆
      • 24,524 Posts
      I suspect that this has something to do with the fact that the username is encoded (line 269 of the processor/register.php file)

      $confirmParams['lu'] = urlencode(base64_encode($this->user->get('username')));


      What happens if you remove the encoding from this?

      $confirmParams['lu'] = $this->user->get('username');


      I know that this is necessary to help prevent security issues, but it might be a place to start looking for the root of the problem. The email browser may be decoding this in a way that breaks the original numeric string; perhaps it's generating a different character set than the original (iso-whatever vs utf8, for example)
        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 might be it, but I thought it might also be a problem with MODX or xPDO, which sometimes use is_numeric() or is_int() to identify "numbers" and assume that any number in a query criterion is an ID rather than a string. So it might be trying to get a user with that ID instead of that username.


        ------------------------------------------------------------------------------------------
        PLEASE, PLEASE specify the version of MODX you are using.
        MODX info for everyone: http://bobsguides.com/modx.html
          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
          • 3749
          • 24,544 Posts
          I should have mentioned this earlier: one other thing you might try is dumping the $scriptProperties array to see where the username is. MODX often pulls the $_POST stuff into $scriptProperties early in a process and ignores the $_POST array from that point on. The $scriptProperties array gets passed along during the process and changing the username there might work.

          Here's how I do it (and this technique is often useful for debugging plugins):

          Create a chunk called debug.

          In your plugin code:

          <?php
          $msg = print_r($scriptProperties, true);
          
          $chunk = $modx->getObject('modChunk', array('name' => 'debug'));
          $chunk->setContent($msg);
          $chunk->save();
          


          It may take a little time because the $scriptProperties array is often monstrous and the username may appear in various places. If there's a 'data' member, that's the best bet.

          And be careful, because in theory, you could corrupt your DB by changing the $scriptProperties array during a process that writes to the DB (though it's never happened to me, Login won't normally be writing anything, and just changing the username should be safe enough).

          I actually put the code above in a function called myDebug() wrapped in if(function_exists), with the option to write or append to the debug chunk.

          After examining the dump, you can often dump just part of the $scriptProperties array, e.g.,

          print_r($scriptProperties['data'], true); 



          ------------------------------------------------------------------------------------------
          PLEASE, PLEASE specify the version of MODX you are using.
          MODX info for everyone: http://bobsguides.com/modx.html [ed. note: BobRay last edited this post 14 years, 1 month 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
            • 38800
            • 35 Posts
            Thanks Bob and Susan - really appreciate your time on this.

            Over the next few days, I'll follow the leads you've flagged up and report back.

            Have a good weekend!
              • 38800
              • 35 Posts
              Wow - 2 weeks have gone by. How did that happen? smiley

              Susan, I did try your suggestion in "reply 12" in this thread, whereby the 2 encoding functions from line 269 of register.php are temporarily removed. But no go, I'm afraid - it still doesn't seem to recognise as valid the URL that is sent by e-mail to the user who's trying to register.

              Bob, I'm ashamed to admit that I haven't tried your suggestion in "reply 14" of the thread because my object-oriented PHP / MODX skills just ain't up to it (YET!). But actually I've ended up working around the problem by telling users that, when logging in, they need to prepend a lower-case "u" to their membership number in order to derive their username. Not as elegant as a proper fix from the users' point of view but, hey, it works!

              So thanks once again to you both for your help on this.
                • 42057
                • 10 Posts
                Just for information. I had the same issue with 404 error during last week. In overall 5% of registrations was not successful. After research together with users I have found that some of them are using a mail program which converts all letters to text. So, there was &amp; in the link instead of &.

                Also, to prevent an unexpected errors I have decided to create a separate page to suppress the 404 error. The idea here is that if user clicks on activation link second time he or she seen the 404 which is unexpected behavior.

                So, my MODX is behind the Nginx proxy. And solution was to configure Nginx properly. Here is the final configuration:
                    location ~* ^/en/e-mail-address-confirmation\.html {
                        if ($args ~* ^(.+)&amp\;(.+)$) {
                            set $args $1&$2;
                            rewrite ^(.*)$ $1 permanent;
                        }
                
                        error_page 404 =200 /en/activation-failed.html;
                        proxy_intercept_errors on;
                
                        proxy_pass       http://127.0.0.1:8080;
                        proxy_set_header Host      $host;
                        proxy_set_header X-Forwarded-Host $host;
                        proxy_set_header X-Forwarded-Server $host;
                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                        proxy_set_header X-Real-IP $remote_addr;
                    }