Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Using the same Magento route frontname for frontend and admin routers

I discovered an issue with Magento routing logic and I would like to see if anyone can confirm this.

Magento stacks routers admin, standard, then default and processes them one at a time. Magento gets the current module name based on the URL (see Mage_Core_Controller_Varien_Router_Standard::match()), then checks if the module should be handled by this router, based on a match to a frontName in the Magento config. If a match is found, it routes it. If not, it continues to the next router.

Config excerpt:

    <admin>
        <routers>
            <myroute>
                <use>admin</use>
                <args>
                    <module>MyNamespace_MyModule</module>
                    <frontName>myroute</frontName>
                </args>
            </myroute>
        </routers>
    </admin>
    <frontend>
        <routers>
            <myroute>
                <use>admin</use>
                <args>
                    <module>MyNamespace_MyModule</module>
                    <frontName>myroute</frontName>
                </args>
            </myroute>
        </routers>
    </frontend>
    

This means that if you use the same name for your frontend router as your admin router, the admin router will always be matched first, even on frontend pages. Your frontend page will now route as is if were an admin page, using the admin base_url, which may be different from your store's URL causing a broken redirect.

Note that this issue is not apparent in Magento instances where the admin base URL is the same as the frontend base URL.

Can anyone confirm that my assesment of the router logic is correct here?

like image 979
kirkmadera Avatar asked May 07 '12 20:05

kirkmadera


People also ask

How does Magento 2 routing work?

Magento 2 routing defines a URL of the module. The entire Magento 2 application flow is based on processing URL request and router classes which are responsible for matching and processing that requests. Here, the router_name is used to find the module. When a request is made in Magento 2, controller/action: index.

What does FrontController do in magento2?

The FrontController class class searches through a list of routers, provided by the RouterList class, until it matches one that can process a request. When the FrontController finds a matching router, it dispatches the request to an action class returned by the router.

How can install custom router in Magento 2?

To create a router first you need to add it to the \Magento\Framework\App\RouterList, which is transferred to the Front Controller and contains all the available routers in the right order. To do this, we use the di. xml file in our module.


1 Answers

You may want to look over Varien/Router/Standard.php as well in particular:

/**
 * checking if this admin if yes then we don't use this router
 *
 * @return bool
 */
protected function _beforeModuleMatch()
{
    if (Mage::app()->getStore()->isAdmin()) {
        return false;
    }
    return true;
}

And this is called within the method match(Zend_Controller_Request_Http $request) as well as collectRoutes($configArea, $useRouterName) as $useRouterName will sometimes return admin and will also return standard for frontend requests. The assumption sounds correct as it all depends on how magento builds and stacks the _routes and _modules private array in this same class: Mage_Core_Controller_Varien_Router_Standard.

I believe in this case you would want to specify the <use> node as standard for frontend and admin for admin, or rewrite the controller action in the <global> node.

I think your best bet is to read over:

  • http://alanstorm.com/magento_dispatch_admin_cms_default_routers

and/or step through the logic with X-debug.

Even Alan Storm in his article writes how the same routers used for frontend and backend shouldn't be the same.

So it looks like this method is here to ensure the Standard router object bails if, for some reason, the store model object thinks its in admin mode. Like the Standard/Admin router relationship, the store object is another one of those things that points to certain parts of the Magento development process being focused on the frontend application first, and then tacking on an admin console later and having to back-port changes.

The store object is a model that really only applies to the frontend/cart application. However, because so much code in Magento assumes the store object exists, it needs to be available to the admin console application. This, in turn, creates trouble at the router level, which is what leads to a check like this. Many layers of abstraction, no defined contracts between classes/modules, and the fear of refactoring created by the lack of tests will always lead to these sorts of situations.

like image 97
B00MER Avatar answered Oct 02 '22 15:10

B00MER