3
  1. User is on the log in page and types in their password incorrectly.

  2. User receives appropriate error notification and retypes in their password and logs in.

  3. User is presented with a 404 page at this URL parameter: /customer/account/loginPost/

  4. User has actually logged it but should have been taken to their dashboard: /customer/account/

Why is there a /loginPost parameter in the URL? We tried just hacking it by making a URL rewrite but that had some interesting symptoms...

Any advice is appreciated.

  • Have you found any solution for this? – Ronak Chauhan Mar 18 '22 at 08:46
  • Any luck figuring out why this is happening? We have the same problem... – Peter Karsai Mar 25 '22 at 09:29
  • My idea BTW is that at some point there must be a redirect to loginPost. Redirects are always GET requests and the loginPost controller is only prepared to handle POST requests, that's why it ends up returning a 404 page. But I can't figure out where the redirect is happening. Also, this only happens 1 out of 20 times or so. – Peter Karsai Mar 25 '22 at 09:31
  • I think I figured it out. I posted an answer. – Peter Karsai Mar 25 '22 at 13:32
  • Same thing is happening for me, seems to be since 2.4.X update, any luck with finding a solution? Cannot see anything relating to this on Github but not tested on a Vanilla 2.4.X instance yet may be a bit niche. – harri Apr 13 '22 at 14:59

3 Answers3

1

This also started happening to me after an update to Magento 2.4.X. Maybe a little niche issue affecting certain configurations as could not get this to happen on 2.4.X demo stores.

For now I have created a quick patch to modify the functionality of /vendor/magento/module-customer/Model/Url.php:

/patches/composer/login-404-issue.diff

diff --git a/Model/Url.php b/Model/Url.php
index f976e8c..8599dcb 100644
--- a/Model/Url.php
+++ b/Model/Url.php
@@ -246,8 +246,11 @@ class Url
     private function getRequestReferrer()
     {
         $referer = $this->request->getParam(self::REFERER_QUERY_PARAM_NAME);
-        if ($referer && $this->hostChecker->isOwnOrigin($this->urlDecoder->decode($referer))) {
-            return $referer;
+        $decodedReferer = $this->urlDecoder->decode($referer);
+        if ($referer && $this->hostChecker->isOwnOrigin($decodedReferer) && !preg_match('/customer\/account\/loginPost/', $decodedReferer)) {
+            return $referer;
         }
         return null;
     }

Above just checks that the referrer being set is not this problematic "loginPost" URL and does not set the referrer in that case as would never want to redirect to that URL. Just apply above patch with composer.

I tried checking over all possible files to find what may have changed but had no luck. I found a reasonably recent commit also fixed our issue but was rejected so went with my version for now until I can find a real solution:

https://github.com/magento/magento2/commit/ffa1cf2600bdd4fde193c434a46b01957ccb4a06

harri
  • 5,465
  • 6
  • 44
  • 100
0

loginPost is the controller to receive login request and do validation, you wouldn't want to rewrite this url. Most likely you have custom code injects invalid redirect url , you may want to debug the loginPost controller or disable your custom/3rd party modules to troubleshoot

Ryan Sun
  • 186
  • 4
0

I think that this is a Magento bug, triggered by a specific sequence of web requests. The following is the result of a few hours of debugging and it's only correct to the best of my understanding.

Request 1 (loading the login page without a referrer)

If the customer reaches the login page without having a referer parameter in their url, the action url of the sign-in form on this page will not have a referer parameter either. This means that when the form is submitted, the referer parameter will not be set.

Request 2 (attempt to sign-in with invalid credentials)

Since there is no referrer set, \Magento\Customer\Model\Url::getLoginUrlParams sets the referrer to a default, which is the current url, /customer/account/loginPost, because we are in the middle of a loginPost action. \Magento\Customer\Model\Account\Redirect::prepareRedirectUrl then checks if we managed to log in or not, and, since we didn't, sets the redirect to the login url that now has the default, incorrect referrer in it.

Request 3 (signing in with valid credentials)

Magento has a setting that determines whether to redirect the customer to the account dashboard after logging in. The default setting is No, which means that the customer should be redirected back to the page where they were before the login. Since during the 2nd request the referrer parameter was set to the loginPost url, it will now try to redirect to that URL. But that url is POST only, hence we are sent to a 404 page instead.

Solution

The easiest solution to this problem is to set Redirect Customer to Account Dashboard after Logging in to Yes. This setting can be found in Magento admin, under Stores > Configuration > Customers > Customer Configuration > Login Options. This means that customers will always be redirected to the dashboard after login, which may not be the best customer experience, but it's better than a 404 page.

Edit

This is now fixed in Magento 2.4.4 (https://devdocs.magento.com/guides/v2.4/release-notes/commerce-2-4-4.html#general-fixes):

Shoppers are now redirected back to the login page as expected after a second failed login attempt. Previously, shoppers were redirected to a 404 page after a second unsuccessful login attempt.

This is the PR that fixed it: https://github.com/magento/magento2/pull/32891. They changed the code, so the referrer URL is only saved for GET requests.

Peter Karsai
  • 160
  • 2
  • 11
  • Interesting workaround, do want a proper fix however... Just want to check, you said in other comment it is intermittent (1 in 20) however for me if you fail a single login then try is does it every time, just wondering if this is a slightly different problem? – harri Apr 13 '22 at 15:01
  • @harri, that depends on the use-case. If you go directly to the login page from a bookmark and the referrer is not set in the bookmark then yes, it will happen every time. If you are browsing your store and you click on some link that takes you to the login page from another page in your store, so you have a proper referrer, then it won't happen. – Peter Karsai Apr 14 '22 at 08:23
  • Ok thanks for clearing that up, not ideal but think I have come up with a temporary patch to get by for now. – harri Apr 14 '22 at 11:30