Https does not switch back to http properly

I'm having the same issue, and I'm sure the warning that pops up when submitting any form is worrying to my users. Are we the only ones with the problem???

Mind if I ask why you have installed for modules?

Here's a copy of my available updates list (quickest way to copy-paste)

Drupal core
Drupal 6.10

Modules
Administration menu 6.x-3.x-dev (2009-Apr-04)
Advanced help 6.x-1.2
Auto Assign Role 6.x-1.0-beta3
Ubercart 6.x-2.0-beta5
CAPTCHA 6.x-1.0-rc2
Charts 6.x-1.0-alpha5
Checkbox Validate 6.x-1.1
Content Construction Kit (CCK) 6.x-2.2
Date 6.x-2.1
Devel 6.x-1.15
FCKeditor - WYSIWYG HTML editor 6.x-2.0-beta1
FileField 6.x-3.0-rc1
Format Number API 6.x-1.4
Formatted Number CCK 6.x-1.1
ImageAPI 6.x-1.5
ImageCache 6.x-2.0-beta8
ImageField 6.x-3.0-rc1
Imagefield Crop 6.x-1.0-beta3
Legal 6.x-2.2-beta4
LoginToboggan 6.x-1.4
Mass Contact 6.x-1.0-beta2
Quiz 6.x-2.1
Open Flash Chart API 6.x-2.10
Profile Plus 6.x-1.1
Rules 6.x-1.0-beta5
Secure Pages 6.x-1.7
Thickbox 6.x-1.2
Token 6.x-1.11
User Read-Only 6.x-1.0
User Protect 6.x-1.2
Views 6.x-2.3

Themes
Acquia Marina 6.x-1.5

Note, this also causes problems with admin menu module, as it often doesn't appear on the https pages that should be http...

I just turned this module on and noticed the same issue. as if that checkbox does nothing. I also have the "Secure Pages Prevent Hijack" module.

i am experiencing the same issue

Me too! Even on 1.8.

Cool. Seeing any overlap in our modules? It doesn't seem this is affecting everyone...

Here is my overlap in modules
=====================

Content Construction Kit (CCK)
Date
Devel
FileField
ImageAPI
ImageCache
ImageField
Secure Pages
Token
Views

Administration menu 6.x-3.x-dev (2009-Apr-04)
CAPTCHA 6.x-1.0-rc2
Content Construction Kit (CCK) 6.x-2.2
Date 6.x-2.1
FCKeditor - WYSIWYG HTML editor 6.x-2.0-beta1
FileField 6.x-3.0-rc1
ImageAPI 6.x-1.5
ImageCache 6.x-2.0-beta8
ImageField 6.x-3.0-rc1
LoginToboggan 6.x-1.4
Rules 6.x-1.0-beta5
Secure Pages 6.x-1.7
Token 6.x-dev
Views 6.x-2.3

(Not 100% on the versions of these modules. Just copied and pasted from the post above and removed the ones I know I don't have.)

OK, so firstly is probably a matter of disabling each one temporarily and seeing whether the problem corrects itself. I'm a little budy now, but I'll let you guys know if I have any luck when I get around to it!

I don't know if this helps, but I had the same thing happen, however I was able to get it resolved, my story is as follows...

1) I enabled Secure Pages and selected "Switch back to http pages when there are no matches", everything worked as promised and I was happy.
2) Later I had an issue with my SSL and had to disable Secure Pages until it was resolved.
3) When I re-enabled Secure Pages, I began to experience the problem as explained above (it wouldn't switch back to http)
4) I disabled Secure Pages module, and then I uninstalled it using admin/build/modules/uninstall
5) I re-installed the Secure Pages module and enabled "Switch back to http..." and it worked correctly.

My guess is that something gets screwed up when changes are made to configuration after the intial settings are made. Hope this helps you figure it out, fortunately for me my version is working properly. Thanks.

Since my site is a live site I'm not really sure what I can do as far as disabling random modules like the ones listed above.

I just tried ptwob132's suggestion and things appear to be working. This may've been an Operator's Error on my part because I was just going off of the way it was acting when I was logged in as the admin. When I open a new browser and try to put an s (https) it redirects me to the right one. I'll keep an eye on it.

oh hey thanks ptwob132! I'm actually done with secure pages until the next annual cycle when I need to accept payment again, but I'll give that a shot! You're a superstar

I experience the same issue when logged in as the admin, but when using the site as an anonymous user or any other type of authenticated user it works fine. So I'm thinking it's an issue specific to User 1. Hope that helps with the debugging.

I was having the same issue, also with user 1 and not other authenticated users. Rather than uninstalling and re-installing securepages, I found that clearing the cache resolved the problem for now. Interesting.

I noticed the same issue.
It works fine as anonymous or authenticated user, but does not switch back when admin.
I have activated the $base_url variable (line 125) in sites/default/setting.php and it seems to fix the problem.

Hi,

I'm experiencing the same problems;

- have enabled secured pages
- checked 'switch back to http pages...'
- non-secure base url: http://www.example.com
- secure base url: https://www.example.com
- checked 'Make secure only the listed pages'
- entered NO listed pages
- Ignore pages:
*/autocomplete/*
*/ajax/*

- I've tried disabling Secure Pages module and uninstalling it
- I've tried setting a base_url in settings.php (although I really shouldn't in combination with Domain module)
- tried disabling clean urls, domain module

Still nothing :(

Any ideas?!

Found the problem in my setup;

In my case the solution was to enter just A url under the listed pages, a fake one will do.
That solved the entire problem and now it's working fine! Even the admin is redirected form https back to http if the url is not listed!

Cheers

Sorry for not attaching a proper patch but I reckon my edit needs some tweaking anyway.
In securepages.module in function securepages_match() on line # 237 it says just to return and do ziltch.
So if no ignore and no match pages are listed on admin/build/securepages it doesn't do a darn thing, no matter if you checked 'switch back to http....'
That's why my temp hack above worked.

EDITED: SEE NEXT POST

I think the code should be changed to: return 1-variable_get('securepages_switch', FALSE);

Maybe there's a better syntax but this seems to work and respect the checkbox setting ;)

Cheers

Sorry, my prev post was an incomplete solution.
Hereby a patch with the correct change.

The problem in my case was with the function securepages_match().
Basically it says;
if current page matches one in the ignore list then....
if current page matches one in the pages list then...
else return and do nothing...

Well it shouldn't return and do nothing just like that.

If one has checked; Switch back to http pages when there are no matches
Plus has checked; Make secure every page except the listed pages.

What should it do? I think it should switch back to http pages when there are no matches as one has checked!?

But in current situation if one had checked; Switch back to http pages when there are no matches
And checked either; Make secure every page except the listed pages / Make secure only the listed pages
But not entered and urls under 'pages' the module wouldn't switch back att all. It only worked if an url was given (fake one would do as mentioned above).

Anyway, I think I've solved it for my case of not switching back properly. I've (finally found out how and) provided a patch.

Cheers

I'm having a very similar issue. For me, the behavior is occurring on either side of the option "Switch to http when no match is found."

Tried clearing caches. No luck.

I have Secure Pages and Secure Pages Hijack Protection. I have tried disabling, uninstalling, and re-enabling both. No luck.

I have tried running ONLY Secure Pages without HP. Nope.

It is affecting non-user1 users (unlike #13).

I can't set $base_url (as #15 suggests) because it would bork my Domain Access configuration, among other things.

And unlike Bartezz (#17-#19), I have specified certain pages which need HTTPS, and they are populated in Secure Pages configuration. So this patch won't help me, unfortunately.

Drupal core
Drupal 6.13

Module overlap (via #8, versions are mine)
Administration menu 6.x-1.5
CAPTCHA 6.x-1.0-rc2
Content Construction Kit (CCK) 6.x-2.5
Date 6.x-2.3
FileField 6.x-3.1
LoginToboggan 6.x-1.5
Rules 6.x-1.x-dev (10-Aug-2009)
Secure Pages 6.x-1.8
Secure Pages Hijack Protection 6.x-1.5
Token 6.x-1.12
Views 6.x-2.6

The site hasn't gone live yet, at least. This was so much nicer to think about than an .htaccess solution, but I guess that's the next stop. Ugh.

Nonetheless, would be thrilled if anyone finds a clue. Thanks. I will keep trying too.

I may have solved my own problem, though it might only help those running Domain Access.

As a Domain Access user, I have numerous domains running (site1.domain.com, site2.domain.com), but I have set up Ubercart and other such significant items to only utilize the base domain (domain.com). So that is the only one that needs SSL.

The "domain URL scheme" setting [/admin/build/domain/settings] for the base domain needed to be set to HTTPS. It seems that Domain Access may have actually be strong-arming the URL scheme back to HTTP for this base domain until I changed the setting. Then I was able to set specific pages as protected within Secure Pages, and I checked "Switch to http when no match is found" again. Seems to be working!

Changing status to needs review since there's a patch at #19.

This is a question in regard to the patch in response # 19 but is specific to drupal 5.x version:

Would the code at line 237 in the 6.x version be replaced at line 239 of the 5.x version?

In other words at line 239, would
return;
be replaced by
return $secure ? 0 : (variable_get('securepages_switch', FALSE) ? 0 : 1);

Thanks.

Hey Jusyjim,

Not a 100% sure but I think so. Give it a shot and let us know!

Cheers

How about it?

Patch does not work for me.

It seems to be a problem with admin menu. I'm using Administration menu 6.x-3.0-alpha3

With and without patch any user role with access to admin menu cannot break out of https.

EXTRA: I do not have the problem with admin menu 6.x 1.5.

I'm having the same issue. Pretty much running the same stuff. Looking forward to a fix? ...or ideas?? ;-)

subscribing

I have solved this issue for me. Testing the appearance of my site in IE I noticed that secure pages was actually working fine. When I went back to Firefox (my browser of choice) things were still not working. After doing some investigation using Firebug (http://getfirebug.com/), I found out that I was referencing files in my drupal theme that were either linked to non-existent file locations (moving things around and testing things out, not always a good thing if not being careful) or some files not being output as https. I solved the issue by cleaning up the files in question. Here were the steps I took:

1: Install Firebug for Firefox
2: Go to one of your secure pages (as listed in the Secure Pages module) using Firefox
3: Open up Firebug (bottom right of Firefox) >> Click the "Net" tab >> Click on the arrow beside "Net" and select "Enabled"
4: Ensure that "All" is selected under the "Net" tab
5: While Firebug is open and the "Net" tab select, refresh the drupal page and observe all of the issues in listed red (it may take some time to populate)
6: Fix each issue accordingly

After fixing the files in question, everything for me is now working as it is supposed to! Yay! I hope this helps!

this module doesn't switch back to http for facebook canvas pages, using a callback url, like mysite.com/fb_cb/

even after DISABLING, UNINSTALLING THE MODULE AND FLUSHING ALL CACHES requests from facebook's api servers are still getting returned through https... ><

sorry, my issue was being caused by another module that was storing https as part of a base_url... secure_pages seems to be good =)

Not that I have the problem myself, but would you mind sharing the name of the other module psi-borg? Just in case it helps someone else :)

Subscribing

We found an interesting solution for this. We noticed that there was a missing image in the CSS for the base theme. When we fixed the problem, the switching issue was resolved. So it looks like when a image is not found (404 will show for the image request in the log), the securepages logic will not switch back from the SSL page.

We switched it back and forth a few times to ensure that we were not going crazy.

Is there some internal logic that would make this an acceptable solution?

Thanks,

I'm having the same problem on two sites: I've checked "Switch back to http pages when there are no matches" and the site doesn't know which type of page has to display "http" or "https". I've read carefully the whole thread several times, checking many things on two completely different sites and I can't have it working.

My final conclusion is that the module doesn't work properly at all when using that "Switch back to http pages when there are no matches" check, well, on two different sites it doesn't work properly at all, since not checking "Switch back to http pages when there are no matches" keeps all pages loading on HTTPS which is not the goal of having that module.

What I've seen is that the module changes alternatively between HTTP and HTTPS. One of the url that I want to keep under HTTPS are all "admin*" pages. I've spent a good amount of time to realize that once I enter on www.mysite.com/es/admin I'm HTTPS, next page inside the admin area is HTTP, next HTTPS, next HTTP, and on and on and on... On my case, even if I try to keep under SSL the "node/*/edit" pages, when I enter on them the page is HTTPS, and if I try to save I receive the unsecure message from the browser, if I cancel and reload the "node/*/edit" page is HTTP, if I reload is HTTPS, if I reload is HTTP and on and on...

I've used the patch on #19, I've carefully revised that my template has not absolute paths (my templates never have absolute paths but I verified it), and the same alternance of HTTP and HTTPS. That module definetely doesn't work for me. And it's sad because it would wonderful to be able to set SSL sites with it... I don't know which would an easy alternative...

I've read on other threads that there are problems with secure pages on multilingual sites, maybe that's the problem I have with the two sites I've commented previously...

I am now using Ubercart SSL in favor of this module, it might not be right for everyone, but it works better and is more stable for my site than the Secure Pages module. Also, the developer of Ubercart SSL responds to and acts on requests and support in a reasonable amount of time and is open to suggestions and improvements.

http://drupal.org/project/uc_ssl

i had the problem of site home page not returning to http when it was supposed to. My setup was, "only protect listed pages." In that field I had one path listed and a carriage return. When i removed the carriage return, it fixed the problem.

Subscribing.

#38: Have a look at #797988: Alternating between HTTP and HTTPS with every page request where I provide a patch for the problem.

Has there been any further development here? Thank you

@yaz085 have a look at my comment in #37 above. I also wrote a blog post about this issue: http://go2.tc/rlC

Hi highrockmedia,

I unfortunately need to also secure the user login block and user register block which is provided by the Secure Pages Hijack Prevention module (requires Secure pages module). I hope Ubercart SSL module will support securing these blocks #874714: support for user login block and user register block

Thanks!

@yaz085, As long as you have clean urls enabled you can exclude and include mulitple custom paths with ubercart ssl. It's not done in the UI but in code but it just works, no bugs!

yea, ubercart ssl has been working great so far. I'm still not sure how to secure the user login block and user register block on a page that is not secured (ie http://www.example.com/home). If you could share how this can be I would appreciate it very much!

@yaz085, might not be appropriate to put that here but check line 45 in 'uc_ssl.module' file, look for function uc_ssl_include_ssl_paths() and uncomment one of the example lines below that and change to your specific path, save and clear cache.

Send me a PM if you need more help. If you open an issue over there, at least that maintainer will actually respond and make an attempt to help you.

Hello All,

The patch above did not fix this bug for me. I have been struggling with switching between http and https when in secured pages (ex: /admin) in a site using multi languages with language negociation configured through the path (ie Path prefix with language fallback.) So I have https://www.mysite/en/admin and https://www.mysite/fr/admin.. etc

I did not want to switch to ubercart_ssl because hardcoding values in a module is just not my cup of tea...

So I found out that the $path variable sometimes contains the language prefix and sometimes dosent... Debugging lead me to find out that calling global $language and checking its value to strip its content from the path was no solution because sometimes $language->language is empty!! (Maybe this is just another bug)

So my fix involved checking if LANGUAGE_NEGOTIATION_PATH is enabled and then looping through all configured languages to remove the language prefix before it gets scanned. Im not sure how to build a patch for this but here I have fixed this by adding this snippet in the very top of function securepages_match($path) {

Like :

function securepages_match($path) {
  /**
   * Check to see if the page matches the current settings
   */
   
    switch (variable_get('language_negotiation', LANGUAGE_NEGOTIATION_NONE)) {
    case LANGUAGE_NEGOTIATION_PATH:
      $language_prefix=substr($path,0,3);
      $language_list=language_list('enabled');
      $language_list=$language_list[1];sort($language_list);
      if (sizeof($language_list)) {
        for ($j=0;$j<sizeof($language_list);$j++) {
          $str=$language_list[$j]->language.'/';
          if ($str==$language_prefix) {$path=str_replace($language_prefix,'',$path);}
        }
      }
    break;
   }
  $secure = variable_get('securepages_secure', 1);
  $pages = variable_get('securepages_pages', "node/add*\nnode/*/edit\nuser/*\nadmin*");
  $ignore = variable_get('securepages_ignore', "*/autocomplete/*\n*/ajax/*");
 
  [... ]
    return !($secure xor $result) ? 1 : 0;
  }
  else {
    return;
  }
}

Hope that this is useful in improving this module.

Thanks Shai, that one helped #38!

Some of the issues noted here could be solved by this patch:

http://drupal.org/node/587000#comment-3970906

I fixed my problem with Secure Pages by excluding CKEditor from showing up on the Secure Pages Admin Settings page. This might be a problem with any wysiwyg editor in drupal. It adds unwanted html tags.

Goto your wysiwyg editor global profile settings (for CKEditor: admin/settings/ckeditor/editg). Choose 'visibility settings', make sure exclude is checked, then add the following to the 'Fields to exclude/include' text box:

admin/build/securepages.edit-securepages-pages
admin/build/securepages.edit-securepages-ignore

This should be similar instructions for whatever wysiwyg editor you use.

#51 @mrfunnypants solution solved my issue, even in D7 and three years later. The prevalence of CKEditor in rendering every page seems to force all pages into HTTPS. Thus, adding the CKEditor path into the Ignore field helped me.