Magento2: Store Switcher not working when customer is logged in - Magento 2.3.3

Created on 9 Oct 2019  路  34Comments  路  Source: magento/magento2

Preconditions (*)


Magento 2.3.3

Steps to reproduce (*)

  1. Create at least 2 store views in Magento.
  2. Create a customer account
  3. Go to a page on your shop and change the store with the store switcher while being logged in with the customer account.

Expected result (*)

  1. You a redirected to the same page of the other storeview

Actual result (*)

  1. The user is redirected to a 404 page because only the store code is changed in the URL.

Solution

I did some digging and found out that the bug is coming from the way the StoreSwitcher is currently implemented. For the moment the code is the following:

https://github.com/magento/magento2/blob/7aa94564d85e408baea01abc5315a0441401c375/app/code/Magento/Store/Model/StoreSwitcher.php#L48-L57

The elements and their position in the $this->storeSwitchers array is the following:

  • cleanTargetUrl
  • manageStoreCookie
  • managePrivateContent
  • hashGenerator
  • rewriteUrl

The problem is that the rewriteUrl Switcher has to receive the target url with the changed store code in order to find the equivalent url for the page on the other store. The problem is that when a customer is connected, the hashGenerator generates a url for the switchRequest and this url is then passed onto the rewriteUrl switcher. Because of that, the rewriteUrl switcher cannot find the equivalent Url and the user is redirected to a non existing url.

Their are 2 solutions for this problem:

  1. Change the position of the elements in the $this->storeSwitchers array in order to assure that the hashGenerator always is the last switcher to be applied.
  2. Rewrite the switch method of the rewriteUrl switcher in order to be able to change the encoded url in the switchRequest.

I think the first one would be the easiest to apply but I am wondering if this could add other bugs to the storeSwitcher.

Let me know which solution would be more appropriate and I will open a PR for this issue.

Store Cannot Reproduce Confirmed Format is valid Ready for Work

Most helpful comment

Alrighty, for the people searching after the fix, I took a couple of hours today to go searching for it and after a bunch of bisecting attempts I finally found the fix over here: https://github.com/magento/magento2/commit/f19c780fb7e31db89bfd9965e177d52ad03dacd7

Adding the sortOrder="1000" to that hashGenerator item fixes the problem in Magento 2.3.3!

All 34 comments

Hi @jojotjebaby. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

  • [x] Summary of the issue
  • [x] Information on your environment
  • [x] Steps to reproduce
  • [x] Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.3-develop instance - upcoming 2.3.x release

For more details, please, review the Magento Contributor Assistant documentation.

@jojotjebaby do you confirm that you were able to reproduce the issue on vanilla Magento instance following steps to reproduce?

  • [x] yes
  • [ ] no

Hi @shikhamis11. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

  • [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
    DetailsIf the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.
  • [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

  • [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

  • [ ] 4. Verify that the issue is reproducible on 2.3-develop branch

    Details- Add the comment @magento give me 2.3-develop instance to deploy test instance on Magento infrastructure.
    - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
    - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!

  • [ ] 5. Add label Issue: Confirmed once verification is complete.

  • [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

@magento give me 2.3-develop instance

Hi @shikhamis11. Thank you for your request. I'm working on Magento 2.3-develop instance for you

Hi @shikhamis11, here is your Magento instance.
Admin access: https://i-24942-2-3-develop.instances.magento-community.engineering/admin
Login: admin Password: 123123q
Instance will be terminated in up to 3 hours.

hello @jojotjebaby
thank you for reporting this issue .. I tried reproducing the issue on magento 2.3-develop instance but It seems that works fine .. can you please specify from which page you are changing store or store view ? also please share url and screenshot if you are able to reproduce it on 2.3-develop instance

Hello @shikhamis11 ,

Thank you for testing out on the 2.3-develop instance. I am switching between 2 category pages on the store.

I also did some tests on the 2.3-develop instance but for the moment it seems to be working fine. This is because there is a difference between 2.3-develop and 2.3.3 for the di.xml file of the store module.

2.3.3:

https://github.com/magento/magento2/blob/7aa94564d85e408baea01abc5315a0441401c375/app/code/Magento/Store/etc/di.xml#L433-L442

2.3-develop:

https://github.com/magento/magento2/blob/68c48d55231de6849195e090e2b3ce750db61825/app/code/Magento/Store/etc/di.xml#L433-L441

It seems that the hash generator has been deleted from the arguments. Do you know the PR that is responsible for this change ?

Thank you !

Here is the commit that added this code to the 2.3.3 tag: https://github.com/magento/magento2/commit/fe7fbce272c0c0fdd06b7eaadede0bd18cfe8212

In order to prevent this bug on 2.3.3, you need to revert the magento2/app/code/Magento/Store/etc/di.xml back to this:

https://github.com/magento/magento2/blob/68c48d55231de6849195e090e2b3ce750db61825/app/code/Magento/Store/etc/di.xml#L433-L441

Once the following line is deleted, the store swticher works for logged in customers.

<item name="hashGenerator" xsi:type="object">Magento\Store\Model\StoreSwitcher\HashGenerator</item> 

Hi @p-bystritsky. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

  • [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
    DetailsIf the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.
  • [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

  • [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

  • [ ] 4. Verify that the issue is reproducible on 2.3-develop branch
    Details- Add the comment @magento give me 2.3-develop instance to deploy test instance on Magento infrastructure.
    - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
    - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!

hello @jojotjebaby
I checked on 2.3.3 there this issue was able to reproduced .. but it seems it is already fixed in magento 2.3-develop instance

@shikhamis11 this bug was introduced in 2.3.3 and will appear in 2.3-dev after merging 2.3.3 with 2.3-dev.

hello @jojotjebaby
I checked on 2.3.3 there this issue was able to reproduced .. but it seems it is already fixed in magento 2.3-develop instance

I opened another issue but it seems that 2.3.3 hasn't been merged into 2.3-dev yet. So we have to wait for this merge before I can provide a PR ....

:white_check_mark: Confirmed by @shikhamis11
Thank you for verifying the issue. Based on the provided information internal tickets MC-21767 were created

Issue Available: @shikhamis11, _You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself._

Hi @shikhamis11. Thank you for working on this issue.
Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:

  • [ ] 1. Add/Edit Component: XXXXX label(s) to the ticket, indicating the components it may be related to.
  • [ ] 2. Verify that the issue is reproducible on 2.3-develop branch

    Details- Add the comment @magento give me 2.3-develop instance to deploy test instance on Magento infrastructure.
    - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
    - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!

  • [ ] 3. If the issue is not relevant or is not reproducible any more, feel free to close it.


@shikhamis11 , are you currently working on this issue ? I would be okay to work on this issue but I would like to know which solution to do:

  1. Change the position of the elements in the $this->storeSwitchers array in order to assure that the hashGenerator always is the last switcher to be applied.

  2. Rewrite the switch method of the rewriteUrl switcher in order to be able to change the encoded url in the switchRequest.

Please let me know and I will submit a PR

Store switching never works when you have multiple domain.tld store views.

Store switching never works when you have multiple domain.tld store views.

In magento 2.3.2, for views in subdomains I was able to circumvent the issue by adding domain to cookies : https://github.com/magento/magento2/issues/22966#issuecomment-494948104, maybe it can works in multiple domain.tld ?
Magento store switch is awfully crap, each update gives another issue... with 2.3.3 I can't have a proper working switch. It's like nothing is tested when they release a new version.

Hi @jhart-efaktory.

Thank you for your report and collaboration!

The related internal Jira ticket MC-21767 was closed as non-reproducible in 2.3-develop.
It means that Magento team either unable to reproduce this issue using provided _Steps to Reproduce_ from the _Description section_ on clean Magento instance or the issue has been already fixed in the scope of other tasks.

But if you still run into this problem please update or provide additional information/steps/preconditions in the _Description section_ and reopen this issue.

What's the status of this ticket? We're also seeing this after upgrading a shop from Magento 2.1.16 to 2.3.3.
If it was fixed on 2.3-develop/2.4-develop, does somebody have a commit which points to the fix? Thanks!

I can confirm we are having this issue too on 2.3.3 (we upgraded from 2.2.7). This ticket should be reopened.

updated 2.3.2 to 2.3.3. and sadly we are experiencing this issue on 2.3.3 too

@magento-engcom-team this ticket should be reopened.

@GuiltyNL: we should first test if this is still an issue on the 2.4-develop branch. It was reported as not being reproducible on 2.3-develop (which became 2.4-develop some days ago). It might mean that a fix is already there.
If a fix is already there, it would be nice if somebody could try to figure out where it is (by reading git logs or doing some git bisect testing for example).
Only if the issue still exists on 2.4-develop, we should re-open the ticket.

Alrighty, for the people searching after the fix, I took a couple of hours today to go searching for it and after a bunch of bisecting attempts I finally found the fix over here: https://github.com/magento/magento2/commit/f19c780fb7e31db89bfd9965e177d52ad03dacd7

Adding the sortOrder="1000" to that hashGenerator item fixes the problem in Magento 2.3.3!

Just a heads up for future readers, this problem also affects the 2.3.2-p2 version.

I have applied changes that hostep brings to our attention, we are running on 2.3.3 and experienced this problem after update from 2.2.2 and now these two files replaced and we deployed it... It seems solved so big thanks !

Have to say that you will need to flush your internet history cache + cookies to see it working.
Thank you @hostep

Applying the sortOrder fixed it for other stores (we have 5), but it fails when going back to the first store (where i logged in), so something else must be missing

I'm having the same problems when I upgraded the Magento from 2.2.7 to 2.2.10

We updated our store to 2.3.4, the problem persists when changing back to the store where the user is logged in

But did you apply the fix?

I started debugging the problem, since it's still happening on 2.3.4.
The proposed patch only removes the processor from the request flow, but that's only working on the symptoms.
After StoreSwitcher/HashGenerator adds some parameters to validate the redirection, and send the redirect, magento process the redirect request and creates a new redirect (still don't know why). But this second redirect is processed by the plugin \Magento\Store\App\FrontController\Plugin\RequestPreprocessor, that removes all query parameters. So when the new request gets to the hash validator, it doesn't have any query parameter to check.

I created a small plugin that adds back the missing parameters (but only in case the signature parameter is set) and now everything works fine. Of course it would be better to fix the existing plugin instead of adding yet another on the critical path.

I started debugging the problem, since it's still happening on 2.3.4.
The proposed patch only removes the processor from the request flow, but that's only working on the symptoms.
After StoreSwitcher/HashGenerator adds some parameters to validate the redirection, and send the redirect, magento process the redirect request and creates a new redirect (still don't know why). But this second redirect is processed by the plugin \Magento\Store\App\FrontController\Plugin\RequestPreprocessor, that removes all query parameters. So when the new request gets to the hash validator, it doesn't have any query parameter to check.

I created a small plugin that adds back the missing parameters (but only in case the signature parameter is set) and now everything works fine. Of course it would be better to fix the existing plugin instead of adding yet another on the critical path.

I am also facing issues after upgrade to 2.3.4 like after login store switcher action goes to 404. So, can you please share the changes you made or guide me.

@bharat1811 in the end it didn't made much difference, so I just left in the patch that removes the HashGenerator class from module-store/etc/di.xml at the end.

When I have time this week I'll create a patch with my debug changes in case someone wants to test it further

I had the same exact issue with my recent plain installation of Magento 2.3.4, after any login you received a 404 page because the URL was wrong.

Magento is installed in the directory "magento2" over my root domain, I temporarily corrected the issue with a redirection in root .htaccess to the proper directory because it previously was redirecting to the root.

Previous behavior after changing store view "disconnected" :
https://MyRootDomain.ca/magento2/stores/store/redirect/___store/english/___from_store/francais/uenc/aHR0cHM6Ly9lbnRyZXIuY2EvbWFnZW50bzIvP19fX3N0b3JlPWVuZ2xpc2g%2C/

Previous behavior after changing store view "connected" :
https://MyRootDomain.ca/stores/store/switchrequest?customer_id=1&time_stamp=1588353257&signature=3d79e953ea42942fd4c9b200fa36eb93659a2fc3fb0b83ec9c73c2e3b685f871&___from_store=english&uenc=aHR0cHM6Ly9lbnRyZXIuY2EvbWFnZW50bzIv

.htaccess file modification in root directory :
RewriteRule ^stores/(.*)$ /magento2/stores/$1 [R=302,NC,L]

Now anyone can change the language store view even logged!

Meantime I am waiting for the proper corrections to the code...

Was this page helpful?
0 / 5 - 0 ratings