How would you propose the best way to handle the following situation?

Site is located at http://www.abc.com/

Certain pages are automatically changed to https://www.abc.com/ by secure pages module.

I haven't got a dev site set up with SSL so haven't tested it myself, but I have a feeling that Mobile Tools is going to clash with Secure Pages, so the site won't know whether to go to https://www.abc.com/ or http://m.abc.com/ (ideally should be https://m.abc.com/

I am thinking the best solution would be to add the URLs that need to be secured to the exceptions list and style them as best as possible to display on the mobile browser.

Comments

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Subscribing

I have the exact same question. While on the server side you can use a wildcard certificate to secure both www and m subdomains with a valid cert, how to manage the proper redirection with the two mobile basepaths is unclear to me.

Maybe there is a way to extend Secure Pages to support more than one non-secure / secure basepath pair. The values are read in one Secure Path function only ( securepages_baseurl() ) in which you possibly could implement a simple workaround with some string matching.

I'll contact Gordon Heydon (Secure Pages maintainer) about this and keep you updated.

Edit: created to following issue in securepage's issue queue: http://drupal.org/node/1242940

jamestombs’s picture

jamestombs CreditAttribution: jamestombs commented

I have got round the problem but simply disabling the redirection.

So the site is always at www.domain.com and secure pages will take care of the http/https situation and then Mobile Tools is set to change the theme on device detection. There is a bit of a problem with the context within panels but using PHP code rather than the provided context fixes that.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Hi James, thanks for sharing your solution. I haven't thought of the possibility of simply using the same domain and just switching themes but it sounds like the right way to go right now.

jamestombs’s picture

jamestombs CreditAttribution: jamestombs commented

It says in the settings page that it isn't recommended, but from testing we haven't come across any problems and should hopefully putting it live late this week.

derhasi’s picture

derhasi CreditAttribution: derhasi commented
Status: Active » Needs review

The case Alexander had in mind, could be fixed by using a more dynamic configuration in the settings.php . I created a sandbox for that on http://drupal.org/sandbox/derhasi/1399172. It provides a form submission to remove the values stored in the database, so the extensive settings.php configuration can take effect. A temaplte for this configuration is default.settings.inc of that sandbox.

I wrote a blogpost on that solution, that might give you more information.

windm’s picture

windm CreditAttribution: windm commented

Hi there,

seems to work! I simply took the code as mentioned in the install.txt and it works as it should... at least as far as I tested the past 30 minutes... ;-)
So if anybody gets any strange effects for special usecases or related to other modules... pls let me/us know. Maybe there are other/new dependencies with other elements I have not tested yet.

All other suggestions (using browscap and switch the theme based on mobile device instead of the URL) did not work properly in my case - so this fix was the last chance to get secure_pages and mobile_tools work together. Thank you!