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.


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...)

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.

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.

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.

Assigned:Unassigned» minorOffense

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.