LoginAsCustomer leaves admin backend unaccessible in multidomain-setup

[Nuranto]

I confirm issue https://github.com/magento/magento2/issues/32796 :

Preconditions (*)

1. Magento 2.4.2

Steps to reproduce (*)

1. Create a multi store, multi domain setup, for example

Domain StoreView test1.test de_DE test2.test en_US

1. Configure Magento such as the StoreView must not be part of the url
2. Configure the backend such as it is available under one of these domains, eg test2.test/admin
3. Create a customer each for both StoreViews
4. Login to the backend and configure the customers so that both can be accessed with the "LoginAsCustomer" feature
5. From the backend login as customer which is assigned to a StoreView on another domain as the backend (eg test1.test)
6. Close the frontend session
7. Hit Refresh in the browser for the backend

Expected result (*)

1. the backend reloads and can be used

Actual result (*)

1. the backend hits - depending on the system configuration - either a redirection loop of death or a plain text site without any style or javascript loaded

Workaround

The backend can be made accessible again by deleting a cookie named "store", which contains the StoreView of the customer.

The problem lies in

https://github.com/magento/magento2/blob/f25fc0398899c2bc126bc877d4147aeea377af64/app/code/Magento/LoginAsCustomerAdminUi/Controller/Adminhtml/Login/Login.php#L250

        if (!$targetStore->isUseStoreInUrl()) {
            $fromStore = $this->storeManager->getStore();
            $redirectUrl = $this->manageStoreCookie->switch($fromStore, $targetStore, $redirectUrl);
        }

The immediate workaround is a patch to change the condition as follows

        if (!$targetStore->isUseStoreInUrl() && $targetStore->getBaseUrl() === $this->_url->getBaseUrl()) {
            $fromStore = $this->storeManager->getStore();
            $redirectUrl = $this->manageStoreCookie->switch($fromStore, $targetStore, $redirectUrl);
        }

This workaround does it's thing for our use case, but there is no warranty it will work in yours

Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.

• [ ] Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• [ ] Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• [x] Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• [ ] Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• [ ] Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant[bot]]

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

• Summary of the issue
• Information on your environment
• Steps to reproduce
• 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.4-develop instance - upcoming 2.4.x release

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

Please, add a comment to assign the issue: @magento I am working on this

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

  :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

:clock10: You can find the schedule on the Magento Community Calendar page.

:telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

:movie_camera: You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

:pencil2: Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[Nuranto]

Additional informations, that might help to reproduce :

web/secure/use_in_adminhtml 1
web/secure/use_in_frontend          1
web/cookie/cookie_httponly          1
web/secure/enable_hsts                0
web/url/use_store                           0

If you can't reproduce, tell me and I will try to find more helpfull settings. (Maybe you can dump me your core_config_data table so I can compare)

[m2-assistant[bot]]

Hi @engcom-November. 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).

  Details

  If 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.4-develop branch

  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.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.

[engcom-November]

Verified the issue on Magento 2.4-develop branch and the issue is not reproducible with below steps performed:

1. Setup Multiple Websites and Store views with different domains
2. My Admin URL: http://magento2.4.local/admin/ Germany Store URL: http://magento2.4.ger.local/ France Store URL: http://magento2.4.france.local/ Default Store URL: http://magento2.4.local/
3. Admin - Stores - Configuration - Customers - Enabled Login as Customer feature (Please find the configuration in below screenshot) Note: This issue is not reproduced even if "Store View to Login to" is "set to Auto-Detection"
4. Stores - Configuration - Customers - Customer Configuration - Account Sharing Options - Share Customer Accounts - Set to "Global" Note: Issue not reproduced even if Share Customer Accounts is set to "Per Website"
5. Created Customers for both the Store Views (Germany and France) from front-end with "Allow Remote Shipping Assistance" enabled
6. Login to admin as admin user and navigate to Customers - All Customers - Edit Germany/France Customer - Click on Login as 7. Customer - Select Germany/France Store view - Login as Customer - No issue
7. Close all Front-end browsers - Refresh Admin pages - No issue.
8. Login as Customer into different store view is also working fine. (Germany customer - View in France Website vise versa) - No issue

core_config_data table data:

 config_id: 438
     scope: default
  scope_id: 0
      path: login_as_customer/general/enabled
     value: 1
updated_at: 2021-08-06 12:01:04
*************************** 400. row ***************************
 config_id: 442
     scope: default
  scope_id: 0
      path: login_as_customer/general/store_view_manual_choice_enabled
     value: 1
updated_at: 2021-08-06 12:28:52
*************************** 401. row ***************************
 config_id: 443
     scope: default
  scope_id: 0
      path: customer/account_share/scope
     value: 0
updated_at: 2021-08-06 12:29:45

@Nuranto, kindly recheck the issue on Magento 2.4-develop branch and provide the missing configurations if any if the issue is still reproducible. Thank you

[Nuranto]

@magento give me 2.4-develop instance

[magento-deployment-service[bot]]

Hi @Nuranto. Thank you for your request. I'm working on Magento instance for you.

[magento-deployment-service[bot]]

Hi @Nuranto, here is your Magento Instance: https://4a4f5f65921fd105fb5cfc65c9ef9ea9-2-4-develop.instances.magento-community.engineering Admin access: https://4a4f5f65921fd105fb5cfc65c9ef9ea9-2-4-develop.instances.magento-community.engineering/admin_2e96 Login: 39b2cc03 Password: 2203928b2acb

[Nuranto]

I did not find a way to reproduce on a fresh install yet. My best guess atm is that there is something to do with filling URL settings via environment variables instead of database. Or maybe non-filled unsecure URLs (I already experienced other issues when unsecure URLs are not set, even if I configured to use secure only...). Anyway, I already spent too much time on this one, so I won't continue investigating to find a way to reproduce.

Most important is that I found the cause of the issue.

If I debug Magento\Backend\App\Area\FrontNameResolver::isHostBackend() (from a backend call), like this :

$backendUrl /* orig */ = $this->scopeConfig->getValue(Store::XML_PATH_UNSECURE_BASE_URL, ScopeInterface::SCOPE_STORE);
$backendUrlTestStoreAdmin = $this->scopeConfig->getValue(Store::XML_PATH_UNSECURE_BASE_URL, ScopeInterface::SCOPE_STORE, 0);
var_dump($backendUrl, $backendUrlTestStoreAdmin);

I get Second store URL (URL of the store which is stored in store cookie) in $backendUrl, and Backend domain URL in $backendUrlTestStoreAdmin...

So there's an issue in the scope resolver when you don't provide the scopeCode. I don't know where exactly the bug is or in which cases it fails.

A quick fix could be to specify 0 store id like I did above. It will fix that issue, and it will be better for performances (no more resolving). However, that would only fix this issue, not the underlaying scope resolving issue.

A solution, while it is not fixed, if someone else has this issue, is to use admin/url/custom_url and admin/url/custom fields. I don't understand why they even exist, but they are at least usefull for this bug..

[m2-assistant[bot]]

Hi @engcom-Hotel. 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).

  Details

  If 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.4-develop branch

  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.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.

[engcom-Hotel]

Hello @Nuranto,

We have tried again to reproduce the issue on the 2.4-develop branch but were unable to do so. And as per your comment, this issue is not reproducible in the 2.4-develop branch. So we are closing this issue for now.

If you still facing the issue either you can create a new ticket or reopen this.

Thanks

[maaarghk]

@engcom-Hotel @Nuranto this issue occurred for me, the proposed patch in #32796 seems like it will resolve it.

the problem is probably on the other end - i.e. what is the specificity of the "store" cookie vs MAGE_RUN_CODE server variables vs the URL being parsed to work out what store to view?

is having multi store configured with two stores with same base URL but NO usage of MAGE_RUN_CODE actually a supported configuration - presumably implemented using switch store button on the frontend + store cookie? if it is NOT a supported configuration there is no need to set this cookie because you are redirected to a URL which can be parsed to determine the store

if it IS then the check should be improved to determine whether setting the cookie is necessary as "has the store code in the URL" is not sufficient (ie the other store view is just http://mage24.france.docker for example with no store code in the url, and the admin is http://mage24.docker/ also with no store code, and yet, there is plainly no need to set the cookie). This is why the patch in #32796 resolves the issue for me. but it's not clear whether the web host (Sonassi, so it strikes me as unlikely) are using a bad / unsupported multistore config.

In any case I don't see any harm in accepting @MarcusSchwarz patch because it won't make anything worse for people on either configuration.