Homepage Redirect After Login Leads To incorrect url

[chackem]

When I have your plugin enabled using a store with force log in set, after I successfully login in it takes me to:

"[store]/customer/section/load/?sections=cart&force_new_sectiontimestamp=false&=1586875817856"

instead of to the homepage.

For stores without forced login enabled there is no problem and I am redirected to the homepage on login.

Once I have logged in and it takes me to the wrong url, I can go to the homepage with no problem.

Any ideas?

Magento 2: 2.3.1 Plugin: 4.0.2

Installed manually from github.

[chackem]

Any ideas? Anyone?

[mustafaeyvazvaimo]

I have a similar situation after a successful registration it takes me to customer/account/createpost

[mattyl]

I have noticied this too - it seems to go away after a while , also when i changed to stop redirecting to dashboard. You get presented with a json type response instead of the page. I am also struggling to whitelist the home page - mysite is in a subfolder. I was forced to put the home page content into a static block and modify the customer_account_login.xml layout to include the block under the login boxes.

[mattyl]

Sorry using php 7.2 and magento 2.3.5

[bigshug]

customer/section/load/?sections=cart&force_new_sectiontimestamp=false&=1593117259775

same here on Magento 2.3.5. Seems pretty random - sometimes it's ok and if you go back the customer is signed in.

Was getting another error with Use Web Server Rewrites turned off

[jschreck]

I've just come across this as well. it happens when in the Stores > Customers > Customer Configuration > Login Options you set it to Redirect Customer to Account Dashboard after Logging in = Yes.

[bigshug]

Good spot!! :o) I've been using my site quite a lot and it the login seems to work fine now that I redirect to the home page.

I'm glad it's working as it's a good extension.

[der-workfloh]

@chackem we added some fixes to the master, do you mind testing your issue, if everything works fine now or report any new issue occured?

[aholovan]

Hi, We've got the same issue after extension update on 2.3.5. Error accours when brouser has some legacy caches from previous Magento (no any error in incognito). And it exists even if we disable AfterLoginPlugin because looks like this is core Magento bug. See https://github.com/magento/magento2/issues/28428 Quick solution to fix the problem is just disable 'Redirect Customer to Account Dashboard after Logging in' under Customer Configuration > Login Options

[gewaechshaus]

Hey, Hallo @websharp,

same here in a 2.3.3 version... The quick solution(disable redirect to customer account dashboard) doesn't help in this case as we have to set the configuration on a website level. (multiple websites). If we disable the redirect to the customer account dashboard in the default configuration, the error doesn't come up, but that's no solution as we need to have the redirect running on the most frequented website.

@aholovan - it isn't browser cache related, you can replicate this in every browsers private mode. It will stuck at the customer section only every 2nd login attempt. So you have to login, logout and login again to trigger the issue.

Cheers, Jan

[denialdesign]

I am also seeing the Json response when logging in. Magento Open Source 2.3.4 using a multistore set up. Log in works fine on one site with the extension off but on the login protected site I see json code. I've tried with "Redirect Customer to Account Dashboard after Logging in" on and off for the store view and both give the same result. https://www.sacportal.co.uk/

[fsspencer]

The issue is on the following file: Controller/LoginCheck.php After the customer logs in, Magento performs a call to the customer/section/load controller. This one is being captured by this LoginCheck class, and it is being used as the referrer. That is why it is redirecting to this page returning that JSON.

Here is the patch that I wrote to fix the issue.

index b1648ae1..2694e630 100644
--- a/vendor/bitexpert/magento2-force-customer-login/Controller/LoginCheck.php
+++ b/vendor/bitexpert/magento2-force-customer-login/Controller/LoginCheck.php
@@ -166,7 +166,9 @@ class LoginCheck implements LoginCheckInterface
         }

         // Set Url To redirect ,using standard method of magento
-        $this->customerSession->setBeforeAuthUrl($url);
+        if (strpos($url, 'customer/section/load') == false && strpos($url, '_=') == false) {
+            $this->customerSession->setBeforeAuthUrl($url);
+        }

         // check if current url is a match with one of the ignored urls
         /** @var \BitExpert\ForceCustomerLogin\Model\WhitelistEntry $rule */

[Echron]

@fsspencer Is your patch correctly working? Looks like your merge requests isn't accepted yet. Need any help? Currently having the same issue but I'm not 100% sure this fix will work in all cases as there might be more URL you need to ignore than 'customer/section/load'

[emrahuyanik]

\BitExpert\ForceCustomerLogin\Plugin\AfterLoginPlugin::afterExecute

  public function afterExecute(LoginPost $customerAccountLoginController, $resultRedirect)
    {
        if (self::REDIRECT_DASHBOARD_ENABLED ===
            $this->scopeConfig->getValue(self::REDIRECT_DASHBOARD_CONFIG)) {
            return $resultRedirect;
        }

        $targetUrl = $this->session->getAfterLoginReferer();
        if (empty($targetUrl)) {
            $targetUrl = $this->defaultTargetUrl;
        }

        /** @var $resultRedirect Redirect */
        $resultRedirect->setUrl($targetUrl);

        return $resultRedirect;
    }

As we can see from above, module is redirecting customer to getAfterLoginReferer after login. But for self::REDIRECT_DASHBOARD_ENABLED case, magento OOTB is working.

\Magento\Customer\Model\Account\Redirect::prepareRedirectUrl

protected function prepareRedirectUrl()
    {
        $baseUrl = $this->storeManager->getStore()->getBaseUrl();

        $url = $this->session->getBeforeAuthUrl();
        if (!$url) {
            $url = $baseUrl;
        }

        switch ($url) {
            case $baseUrl:
                if ($this->session->isLoggedIn()) {
                    $this->processLoggedCustomer();
                } else {
                    $this->applyRedirect($this->customerUrl->getLoginUrl());
                }
                break;

            case $this->customerUrl->getLogoutUrl():
                $this->applyRedirect($this->customerUrl->getDashboardUrl());
                break;

            default:
                if (!$this->session->getAfterAuthUrl()) {
                    $this->session->setAfterAuthUrl($this->session->getBeforeAuthUrl());
                }
                if ($this->session->isLoggedIn()) {
                    $this->applyRedirect($this->session->getAfterAuthUrl(true));
                }
                break;
        }
    }

In the OOTB method above, we can see if getAfterAuthUrl is null, we will use beforeAuthUrl as afterAuthUrl.

If request is ajax, \BitExpert\ForceCustomerLogin\Controller\LoginCheck::execute will set beforeAuthUrl, it won't set afterAuthUrl as you can see below

$this->customerSession->setBeforeAuthUrl($url);
....
 if (!$this->isAjaxRequest()) {
            $this->session->setAfterLoginReferer($path);
}

The patch I applied is below

diff --git a/vendor/bitexpert/magento2-force-customer-login/Controller/LoginCheck.php b/vendor/bitexpert/magento2-force-customer-login/Controller/LoginCheck.php
index b1648ae12..7cb25d1d3 100644
--- a/vendor/bitexpert/magento2-force-customer-login/Controller/LoginCheck.php
+++ b/vendor/bitexpert/magento2-force-customer-login/Controller/LoginCheck.php
@@ -166,7 +166,9 @@ class LoginCheck implements LoginCheckInterface
         }

         // Set Url To redirect ,using standard method of magento
-        $this->customerSession->setBeforeAuthUrl($url);
+        if (!$this->isAjaxRequest()) {
+            $this->customerSession->setBeforeAuthUrl($url);
+        }

         // check if current url is a match with one of the ignored urls
         /** @var \BitExpert\ForceCustomerLogin\Model\WhitelistEntry $rule */

[shochdoerfer]

This seems to be fixed with #206, at least I could not reproduce it anymore. Tested it with Magento 2.4.4 and the dev-master version of this module. We'll push a new release in the next few days.