Form actions aren't properly altered to http/https when the site is installed in a subdirectory [#1376798]

With the patch from #471970: DrupalWebTestCase->getAbsoluteUrl should use internal browser's base URL applied and running Drupal at the server root (e.g., http://drupal.dev), I get three test failures in the Secure Pages test suite. However, when running Drupal in a subdirectory (e.g., http://localhost/drupal), I get five failures.

It looks like this is due to a bug where form actions aren't properly being altered to http/https in this case. There is some code in securepages_can_alter_url() that tries to play around with $base_path and $base_url, and that's what's causing it. For the life of me I can't figure out what that code is trying to do, but I'm pretty sure it's unnecessary, and it's definitely broken. The attached patch removes it.

Applying this patch results in consistent test behavior regardless of whether the site is installed in a subdirectory (3 failures either way).

Comment	File	Size	Author
	securepages-alter-url.patch	760 bytes	David_Rothstein

Comments

Comment #1

grendzy commented 30 December 2011 at 18:06

The tests should pass 100% at the server root, with some conditions. You need the core patches linked from the home page, securepages should be disabled during the test, and admin/config/development/testing should be accessed via HTTP. (I realize after writing this how silly it sounds, so I've also opened #1389630: Make tests run in HTTPS mode).

I think the purpose of securepages_can_alter_url() is to prevent changing the #action when it points to an external site (e.g. a third-party sign-up form). If that's true, we might be able to simply replace it with a core function (url_is_external() comes to mind, though it has some very odd behaviors of its own). Previous versions of securepages used hook_boot and so had to forego many core url handling functions.

We have a possibly related issue with the form_alter where it doesn't work if the form #action has a language prefix: #1145292: Problem with i18n/improper redirect.

Comment #2

bisonbleu commented 18 June 2012 at 15:20

I'm running a multilingual website in a subdirectory (public_html/mysite.com) and ran into the same issue. Secure Pages is unable to secure paths such as:

- mysite.com/en/charitable-donations
- mysite.com/fr/dons-de-bienfaisance

@ admin/config/system/securepages, I tried the following paths:

charitable-donations --> FAILED
*/charitable-donations --> FAILED
en/charitable-donations --> FAILED

Applying the securepages-alter-url.patch provided above fixes this issue. The following entries (no prefix required) now secure both English and French forms as expected.

charitable-donations --> SUCCESS
dons-de-bienfaisance --> SUCCESS

Many thanks!

Comment #3

bisonbleu commented 18 June 2012 at 19:04

Supplemental sub-issue.

After applying the 'securepages-alter-url.patch', both forms identified in #2 resolve to https URLs and are recognized as such by browsers through the display of a 'https' URL and a 'padlock' shaped icon.

But upon submitting the form the 'https' reverts back to a 'http'. I'm assuming this behavior stems from the fact that I'm securing only 'charitable-donations'. The URL that immediately follows clicking the Submit button is NOT.

Can someone suggest what other paths I should secure to remain under 'https'? I have tried the following without any success.

charitable-donations/*
charitable-donations*

p.s. In the meantime, I have disabled the 'Switch back to http pages when there are no matches ' option to preserve 'https'. Seems like a viable solution. Although knowing what paths to secure would definitely be a plus.