On the configuration page:
Make secure only the listed pages is selected.
Pages:
node/add*
node/*/edit
user*
admin*
as well as my Ubercart /cart and /cart/checkout pages

Ignore pages:
*/autocomplete/*
*/ajax/*
The pages listed here will be ignored and be either returned in http or https. Enter one page per line as Drupal paths. The '*' character is a wildcard. Example paths are 'blog' for the blog page and 'blog/*' for every personal blog. '' is the front page.

With Secure Pages configured this way ajax and autocomplete callbacks should work whether they are returned as "http://" or "https://" and whether or not they are called from secure pages like those listed above. At least that's my understanding of this setting.

However, I am getting the following errors with ajax and autocomplete:

On the page https://mydomain.com/node/add/user-notes I get the following error when trying to edit a user reference field:
"An HTTP error 0 occurred.
"http://mydomain.com/userreference/autocomplete/field_user"

On the page https://mydomain.com/admin/build/views/add I get the following when trying to create a new view:
"An HTTP error 0 occurred.
"http://mydomain.com/admin/views/ajax/autocomplete/tag"

What's happening here seems to be that function calls are being made from https pages and the functions are returning http pages. It seems that Secure Pages should ignore them and allow the http returns because they are ajax and/or autocomplete pages. However, that's not happening. This is occurring both on a live site and a test site.

I've seen other related posts concerning not switching between http and https but none that directly addressed this issue.

Comments

cjscullyca’s picture

cjscullyca commented

One thing I forgot to include in my original post. I removed "admin*" from the list of pages to secure and retested and the errors were eliminated. When I reverted back to the original settings as above, the errors returned.

vacilando’s picture

vacilando commented

Subscribing.

Charles Herring’s picture

Charles Herring commented

Subscribing.

wiredescape’s picture

wiredescape commented

Also had autocomplete errors with SecurePages. Found this http://benbuckman.net/tech/10/06/drupal-fix-ajax-and-secure-pages which points to $base_url in settings.php which needs to be either not used or toggled between http and https.

Quote from Ben Buckman:

The solution is to toggle https:// in $base_url so it's not seen as cross-domain, and that's most easily done by putting this line in settings.php (changing mysite.com as needed):

$base_url = ((isset($_SERVER['HTTPS']) && $_SERVER['HTTPS']=='on') ? 'https://' : 'http://') . 'mysite.com';

Hope this helps,
Doug

hadsie’s picture

hadsie commented

I believe this is caused by the way core generates the autocomplete links using url(). Securepages has it's own securepages_url() function, that I think needs to be used when using the url() call. I'm not sure if there's an easy way around this besides overriding the core autocomplete functionality...

Maybe just overriding theme_textfield() could do the trick too, since that's where it seems to have the call to url(). Haven't tried it though.

grendzy’s picture

grendzy commented
Category: bug » support
Status: Active » Fixed

The best solution is to not set $base_url at all; Drupal will detect it automatically. If you must set this value in settings.php, then #4 is the correct solution.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

DedSec’s picture

DedSec commented

Bumping this.

I want ALL pages to be HTTPS secured, except for specific ones (screens/*).

Setting "Make secure every page except the listed pages" and adding "screens/*" to the pages field results in the page redirecting to HTTPS and this debug message:
SP: Secure path (Path: "node/601", Line: 1, Pattern: "screens/* ")

Adding "screens/*" to the ignore field instead results in:
SP: Ignored path (Path: "node/601", Line: 1, Pattern: "screens/* ")
But the user is still redirected to HTTPS.

Note that I do not have a value set for base_url, and disabling Secure Pages fixes this issue.

DedSec’s picture

DedSec commented
Version: 6.x-1.8 » 7.x-1.x-dev
Category: Support request » Bug report
Status: Closed (fixed) » Needs work
DedSec’s picture

DedSec commented

Solution:

In securepages.module, on line 248:

Replace
return $is_https ? 1 : 0;
with
return false;

I can't think of any good reason why this function should return NOT false when a page matches the ignore rules. Also, the value of $is_https var isn't even relevant in this circumstance. If the page is loaded as https or http, the protocol should not be modified if listed in ignore.

astonvictor’s picture

astonvictor commented
Status: Needs work » Closed (outdated)

I'm closing it because the issue was created a long time ago without any further steps.

if you still need it then raise a new one.
thanks