For example, when a user is using a tabbed browser, he may switch to the full site in one tab and then click the "Full Site" link in another tab. He should not encounter an "Access Denied" error just because he has a stale link.


minorOffense’s picture

Status:Active» Postponed (maintainer needs more info)

I'm not sure what you mean by stale links.

Is the user authenticated on the mobile site and switches to the desktop one and isn't logged in anymore?

If that's the case, you'll have to adjust your cookie domain settings in settings.php

Otherwise could you provide more details on the circumstances? (i.e. browser, auth status, sample urls, etc...)

Devin Carlson’s picture

Component:User interface» Code
Status:Postponed (maintainer needs more info)» Closed (cannot reproduce)

I haven't been able to duplicate this. If you're not currently running the latest 6.x-2.x-dev version of Mobile Tools you might want to try upgrading and see if your issue persists.

agittins’s picture

Status:Closed (cannot reproduce)» Active

I've been encountering the same issue, I'll try and explain what seems to be going on for me...

I'm using theme switching only - same domain, same path.

The root cause of the problem

If I am currently using the desktop site and I manually enter a link to:
then I get an "Access Denied" error.

Likewise if I am on the mobile site and enter a "mt/desktop/.." url.

This appears to be because the code that mt uses to switch the Full Site/Mobile Site menus on and off also prevents access to the path, thus giving the error instead of sending the user a redirect.

It's a bit of a chicken and egg thing - on the one hand, the user should never be presented with (or following) a switch link destined for the site they are already on (eg, a desktop user should only see switch links to the mobile site). However on the other hand, if a user does somehow find/enter/click such a link, it would be much better to send them to the right place rather than just bombing with an access denied page.

This happens in mobile_tools_menu_link_access - problem is, if we "fix" it by allowing access to the path, then we break the menu visibility in that mobile and desktop users will see both switch menus. At least it would work, but it's ugly and a bit silly :-)

I don't know how this could reasonably be fixed - perhaps someone more familiar with the drupal menu api will know a workaround (should we be using another method to set menu visibility)?

Possible band-aid solution

The only reason I have come across this issue is because google seems to love indexing my switch pages (ie, - this had me scratching my head for quite a while (and stuffing around with canonical metatags as well in the hope I could avoid the root issue) until it clicked - mobile_tools_menu_switch_site does a 302 redirect.

It seems to me that (at least in my case with theme switching only) it really should be a 301 redirect. By using a 302 it's signalling to crawlers that this is still a valid url (which as you can tell from the above, isn't necessarily true) so then it's up to the search engine to decide whether to store this url or replace it with the new one. From what I'm seeing, google keeps both (and I guess therefore splits the google love between them). This is pretty undesirable for SEO as well as user-experience reasons.

I notice that we have a copy of drupal_goto in the module itself, but probably better to change the call just for clarity:

--- tmp/mobile_tools.module     2012-07-08 01:37:38.000000000 -0400
+++ mobile_tools/mobile_tools.module    2012-07-08 01:37:59.000000000 -0400
@@ -131,7 +131,7 @@

   $querystring = drupal_query_string_encode(array_merge($_GET, array('device' => $site)), array('q'));

-  drupal_goto($url, $querystring);
+  drupal_goto($url, $querystring, null, 301);


(Note: I don't know how the fragment part is/should be handled)

This will stop google indexing the /mt/ paths and index what they point to instead. As a longer-term solution, this works for the only case I have seen - google search results. If there are other places the path gets stored though (other search engines, user cache logs etc) then it will still cause "access denied" but _only_ in cases where the user already has a cookie set for the "other" site.

In summary

  • The mt/ paths cause "Access Denied" errors when a user already has a cookie set for their device type AND they click a link to switch to that same device type.
  • Due to the 302 redirect default of drupal_goto, google happily indexes the switch path, not the destination url
  • Visitors clicking these search results get sent to the mobile site by default (at least in my case)
  • Clicking these links also defeats auto-detection since the device type gets decided by the path they requested
  • Visitors who have visited previously and have a matching device cookie setting will get "Access denied" errors instead of the page they request.
  • There are two bugs and two fixes required:
    • By using a 302 redirect, we tell search engines it's ok to index the "switch link" page. Fix: use 301 redirects (it's then up to the destination page to declare if it is or is not the canonical page)
    • By having a menu link as the switch, where both path access and menu visibility are defined by the same method, we produce urls that interrupt the user experience depending on what cookie values they have set. Fix - no idea.
minorOffense’s picture

Status:Active» Needs work

We encountered this in the 3.x branch for Drupal 7. We no longer use the menu system for displaying the list of links.

I'm not sure a 301 is the right answer either. It's not a moved permanently link, it's just another link. I would prefer to put a rel="nofollow" on those menu items. I know that won't stop all search engines (though neither would a 301 really) but I think it might fit better.

Since changing the way the links are generated would require a structural change to 2.x I probably won't push a fix that part of the issue. I'm ok with the new link attributes though.

Looking forward, the 3.x version does a much (much!) better job of switching URLs.

minorOffense’s picture

Assigned:Unassigned» minorOffense
AlfTheCat’s picture

I have found a work around by installing the path_redirect module.

I had this issue on my homepage, and added a redirect from my desktop site like this:

from: to <--my 'normal' homepage.

cparkner01’s picture

Issue summary:View changes

I have been getting these 404 errors in webmaster tools for a few weeks now all mt/desktop/node/xxx .The strange thing is I installed mobile tools a while ago, didn't like the module and removed it from my site. Google seems to keep picking this up in crawler errors as being linked to on all my pages. I can't find the links in my source code for the pages, and am not sure how the crawler is finding them. Any help would be greatly appreciated, or pointing me to a file that must be creating this link. The other thing is I am now using mobile switch, could mobile switch be creating this mt/desktop 404?

cparkner01’s picture

could I be getting 404 errors in webmaster tools from elements of mobile tools left in my database? I noticed many mobile tools entries in the database under variables. Specifically I am looking for some sort of code that is directing the googlebot to mt/desktop/node/xxxx