Magento2: Cookie collision with multiple magento instances

[Detzler]

While running a Magento instance on a TLD domain and an instance on a subdomain, no session-dependent component e.g login/reg-form does work on the subdomain-instance, because the TLD-session-cookie overwrites the subdomain-cookie.

Preconditions

1. Magento instance on https://example.net (without www.)
2. Magento instance on https://subdomain.example.net

Steps to reproduce

1. Open the TLD instance in the browser (cookie gets created)
2. Open the subdomain instance in the browser
3. On the subdomain instance: Try to login as a customer or as a admin in the backend.

Expected result

1. The cookies should not collide

Actual result

1. The cookies collide

If I'm right, there is no possibility to tell the browser via HttpHeader that my tld-cookies should only apply to the tld domain and should not inherited by subdomains. Thats why we need at least the possibility to change the cookie-name via env.php

From my current POV, the prime solution would be, that the cookie name gets generated randomly at the magento installation.

[orlangur]

Magento instance on https://example.net (without www.)
Magento instance on https://subdomain.example.net

Why are those not represented as different stores of the same Magento instance?

[Detzler]

Well, it's required by the shop owner's business logic.

[orlangur]

Like it's necessary to have different customer bases or something?

So, basically if such case is only used by 0.0001% of merchants there is a chance it is not going to be fixed in core.

[Detzler]

Like it's necessary to have different customer bases or something?

There are many use cases which leads the shop owner to setup an independent second Magento instance. If seen often reasons like:

• 3rd party ERP is able to provide integration to Magento ONLY if the instance is a non-multi-store-instance (blame them or not)
• the second subdomain-instance is a B2B-Store, which should run independent of the b2c-TLD-instance on https://b2b.example.net
• the custom written modules are not capable of dealing with multi store, so in that cases one makes just a copy of Magento instead of making the code multi-store-aware
• subdomain is used for a testing/staging instance (the common one)

Im wondering that you have never seen such setup?
Why do you suppose that it only affects 0.0001% of merchants? Very reckless analysis, isn't it.

In this issue, I have described not a symptom. It's a cause.
In the most cases you will read in the github-issues and stackoverflows etc. something like "Not able to login" or "My forms does not work". Those are symptoms which are sometimes caused by this cookie-problem.

Indeed this software behaviour is not that important as like as other issues which should be fixed 10 years ago, but at least it should get onto the ToDo-list.

[orlangur]

IF such case is only used by 0.0001% of merchants

@Detzler note the "if" part :) Thanks for detailed insight, use cases seem quite awkward to me I must say, let's wait for the triage by magento-engcom-team.

[pemann]

@Detzler can you be more specific. What is the same and collides between the two cookies?
I have setup just like this (xyz.com and test.xyz.com) but I haven't got any problems with cookies (yet).

[Detzler]

hi @pemann, do you have two independent magento installations?
Could you delete your cookies and try again:

1. login into the admin area at xyz.com
2. login into the admin area at test.wyz.com

You should fail at the second step. If not, could you share your cookies including host (obfuscated) and expiration date?

Tell me your Magento version please.

[pemann]

Hi @Detzler sorry about confusion. Actually, I don't have setup like that. I do have test.xyz.com and xyz.com, but admin-panels are on different domains (multistore and main domain is different).

[andyexeter]

Same issue here. There should be an option to set the domain for the admin cookie. Setting the default cookie domain to example.net has no effect and the admin cookie domain is still set as .example.net

[ghost]

Duplicate of #17323