Magento admin URL routing wrong detection and CORS errors

zapotocnylubos commented 1 year ago

Preconditions and environment

Magento version 2.4.6-p1
Clean install
Enable and set Custom admin url
Trying to have an administration server separate from web nodes

Steps to reproduce

Enable and set the admin path to "/admin123" (in env.php)
Create a frontend (store_view) on the domain "m2.domain.local"
Set the custom admin URL to "admin.m2.domain.local"
Set default base url to "m2.domain.local"
Set the default base url for admin to "admin.m2.domain.local" (in database for scope_id = 0 or via env variable CONFIG__STORES__ADMIN__WEB__UNSECURE__BASE_URL: 'http://admin.m2.domain.local/')

Expected result

The administration panel should not be accessible via "m2.domain.local/admin123". This request should return a frontend 404 error.
The administration panel should only be accessible through "admin.m2.domain.local/admin123". This request should display the login for the administration panel.
Static files should be loaded from the correct custom admin URL domain and not from the default frontend.

Actual result

The Magento routing mechanism for detecting whether the current page is part of the administration panel seems to have a flaw. Instead of checking if "m2.domain.local" is equal to "admin.m2.domain.local," it checks if "admin.m2.domain.local" contains "m2.domain.local" as a substring. This condition evaluates to true, allowing access to the administration panel via the frontend URL. However, it leads to CORS errors when loading static files due to the different domains used.

Additional information

https://github.com/magento/magento2/blob/35e8e434be0b21072382b3f91c71678efc0242c1/app/code/Magento/Backend/App/Area/FrontNameResolver.php#L138

This issue can be found in the source file "vendor/magento/module-backend/App/Area/FrontNameResolver.php" at line 138
stripos("admin.m2.domain.local", "m2.domain.local") !== false evaluates to true. But current domain is m2.domain.local, and it is not part of the administration.
Using a different port for administration will not resolve the issue either, as it would still satisfy the condition stripos("m2.domain.local:8080", "m2.domain.local") !== false which evaluates to true.

Release note

No response

Triage and priority

[ ] 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] commented 1 year ago

Hi @zapotocnylubos. Thank you for your report. To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release
For more details, review the Magento Contributor Assistant documentation.
Add a comment to assign the issue: @magento I am working on this
To learn more about issue processing workflow, refer to the Code Contributions.

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, join the Community Contributions Triage session to discuss the appropriate ticket.

m2-assistant[bot] commented 1 year ago

Hi @engcom-Bravo. 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).
[ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
[ ] 3. Add Area: XXXXX label to the ticket, indicating the functional areas 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.

Amelia792 commented 1 year ago

Check your Magento configuration settings for the admin URL. Ensure that it is correctly set in the app/etc/env.php file or through the Magento Admin Panel. Verify that the web server's rewrite rules are properly configured to handle the Magento admin URL. Clear your Magento cache and browser cache to ensure that any previous routing configurations are not causing conflicts. If the issue persists, consult Magento's official documentation for Ehsaas Kafalat program or reach out to their support for specific guidance. CORS Errors:

Cross-Origin Resource Sharing (CORS) errors occur when a web page makes a request to a resource from a different domain, protocol, or port. These errors are typically related to security restrictions imposed by the browser. Ensure that your server is correctly configured to allow cross-origin requests. This may involve setting appropriate response headers, such as Access-Control-Allow-Origin, on the server-side.

zapotocnylubos commented 1 year ago

I have debugged the problem, this is not helping @Amelia792

zapotocnylubos commented 1 year ago

The solution for me was to create a composer patch (for magento/module-backend) like this

diff --git a/App/Area/FrontNameResolver.php b/App/Area/FrontNameResolver.php
--- a/App/Area/FrontNameResolver.php
+++ b/App/Area/FrontNameResolver.php
@@ -135,7 +135,7 @@
         $host = (string) $this->request->getServer('HTTP_HOST', '');
         $hostWithPort = $this->getHostWithPort($backendUrl);

-        return !($hostWithPort === null || $host === '') && stripos($hostWithPort, $host) !== false;
+        return !($hostWithPort === null || $host === '') && stripos($hostWithPort, $host) === 0;
     }

     /**

because I want (and this should be a correct solution) that current domain (host) and admin domain (host) should match from the start of the string, not somewhere in the middle

engcom-Bravo commented 1 year ago

Hi @zapotocnylubos,

Thank you for reporting and collaboration.

Verified the issue on Magento 2.4-develop instance and the issue is reproducible.Kindly refer the screenshots.

Steps to reproduce

Install Magento and make sure it is working URL should be m2.domain.local

Enable and set the admin path to "/admin123" (in env.php), and make sure admin UI logs in after changing the admin path
Create a frontend (store_view) on the domain "m2.domain.local"
Set the custom admin URL to "admin.m2.domain.local". Also, make sure u r updating the virtual host and host files accordingly. Restart the httpd server
Access using a custom URL, ur application should work

issue :-

The Magento routing mechanism for detecting whether the current page is part of the administration panel seems to have a flaw. Instead of checking if "m2.domain.local" is equal to "admin.m2.domain.local," it checks if "admin.m2.domain.local" contains "m2.domain.local" as a substring. This condition evaluates to true, allowing access to the administration panel via the frontend URL. However, it leads to CORS errors when loading static files due to the different domains used.

admin url is different

frontend is different

Hence Confirming the issue.

Thanks.

github-jira-sync-bot commented 1 year ago

:white_check_mark: Jira issue https://jira.corp.adobe.com/browse/AC-9216 is successfully created for this GitHub issue.

m2-assistant[bot] commented 1 year ago

:white_check_mark: Confirmed by @engcom-Bravo. Thank you for verifying the issue.
Issue Available: @engcom-Bravo, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

zapotocnylubos commented 8 months ago

Hi, this is a single-line patch. Should I prepare PR with the changes mentioned in my patch?

hostep commented 7 months ago

@zapotocnylubos: that would probably speed up the delivery of the fix indeed, so go for it :)

dannymorson commented 5 months ago

Check your Magento configuration settings for the admin URL. Ensure that it is correctly set in the app/etc/env.php file or through the Magento Admin Panel. Verify that the web server's rewrite rules are properly configured to handle the Magento admin URL. Clear your Magento cache and browser cache to ensure that any previous routing configurations are not causing conflicts. If the issue persists, consult Magento's official documentation for Ehsaas Kafalat program or reach out to their support for specific guidance. CORS Errors:

Cross-Origin Resource Sharing (CORS) errors occur when a web page makes a request to a resource from a different domain, protocol, or port. These errors are typically related to security restrictions imposed by the browser. Ensure that your server is correctly configured to allow cross-origin requests. This may involve setting appropriate response headers, such as Access-Control-Allow-Origin, on the server-side.

What is this Man?

zapotocnylubos commented 5 months ago

I don't know, I thought it was some AI/bot response

okunevaeliza commented 1 month ago

The issue of Magento admin URL routing detection and CORS (Cross-Origin Resource Sharing) errors typically arises when there are misconfigurations in the setup, such as incorrect base URLs, insecure protocols (HTTP vs. HTTPS), or misaligned server configurations. Here's how these problems manifest and some potential solutions:

Common Causes:

Wrong URL Routing: Incorrect Admin URL: This happens if the base URL for the Magento admin is not configured properly. It can cause routing issues where the system is unable to direct requests to the correct admin panel. Unsecure Base URL (HTTP/HTTPS conflict): If your Magento store runs on HTTPS but your admin panel URL is still set to HTTP, or vice versa, this could cause issues with routing and resource loading. CORS Errors: Cross-Origin Requests Blocked: CORS errors occur when your Magento admin tries to load resources (like images or scripts) from a different origin (domain, subdomain, or protocol) and the server is not configured to allow this. Mixed Content: Having both HTTP and HTTPS resources can cause browsers to block content, leading to errors in loading resources from the Magento admin panel.

Steps to Resolve the Issues:

Fix Admin URL Routing:

Update the Base URLs: Ensure the correct base URL is configured in your env.php file or through the Magento backend. rust Copy code 'web' => [ 'base_url' => 'https://yourstore.com/', 'base_url_secure' => 'https://yourstore.com/', ] Enable URL Rewrites: In the Magento backend, under Stores > Configuration > Web > Search Engine Optimization, enable Use Web Server Rewrites. Resolve CORS Errors:

Update .htaccess or Nginx Configuration: Allow cross-origin requests by adding proper headers to the server configuration. csharp Copy code Header add Access-Control-Allow-Origin "*" Use the Same Protocol (HTTPS): Ensure both the Magento storefront and admin panel use the same protocol (either HTTP or HTTPS) to avoid mixed content issues. Clear Cache:

Clear Magento cache from the command line or admin panel to ensure changes take effect: bash Copy code bin/magento cache:clean bin/magento cache:flush For detailed support or to explore more tailored solutions, visiting the Knoxville Insurance Store website won't directly help with Magento issues, but for insurance services, they can be a reliable resource here.

If you're still having trouble, you might want to consult Magento documentation or reach out to a developer for further assistance.

chittima commented 1 month ago

Thank you for your contribution! The Adobe Commerce Engineering team is working on the issue which you have addressed in this PR. Team will cherry pick the commits from your PR if we found solution is applicable and may do further investigation to cover additional scenarios as needed. We will reach out to you if we need more information. For now, you can pause work on this PR. We will notify once the issue is fixed. Thank you once again!

magento / magento2