Stale links to mt/desktop/<path> produce Access Denied errors

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

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: http://my.site.com/mt/desktop/path/to/content
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, http://my.site/mt/mobile/path/to/content) - 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:

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.