I have a site using Ubercart 6.2.6 and Secure Pages 6.1.9.

In the secure pages settings, I do not have "Switch back to http pages when there are no matches" checked. I do not have anything entered for the following fields: "Non-secure Base URL: " "Secure Base URL: "

Under "Make secure only the listed pages." I have the following defined:

user/*
cart*
cart
donate

In addition to these, I also have set up all the product pages to load using https://

The problem with this setup is when people are done shopping, if they go back to browse other pages on the website, all pages of the site continue loading using https:// . I have social media related elements of the site that do not load or cause errors when loaded onto an https:// page (Twitter widget, Facebook/Twitter/Linked In share buttons). That is because they are not secure elements.

IE sends a prompt asking "Do you want to view only the webpage content that was delivered securely? The webpage contains content that will not be delivered using a secure HTTPS connection, which could compromise the security of the entire webpage".

So naturally people are going to select Yes when that prompt comes up. From that point forward, nothing on the website delivered from an insecure URL will work.

I would like to check the box that says "Switch back to http pages when there are no matches" and define the "Non-secure Base URL: " as http://www.domain.com and define the "Secure Base URL: " as https://www.domain.com. Doing that works to solve the problem described above. Only the pages that are supposed to load securely do so when these are set.

But the problem with when I set it up this way is a certain (unknown) percentage of the computers that try to place store orders cannot get the cookie info to pass properly when the jump is made from http:// to https:// . When those end-users click an "Add to Cart" button, they get the following message "There are no items in your cart" and they cannot get the item to pass into the cart, and then can't get to checkout. Only when I change the settings to how I have them now is that problem solved. Note also that the reason I make the product pages secure instead of just the cart and checkout pages is because that allows people to be on an https:// page PRIOR to adding the item to their cart. That way an https:// cookie should be set at that point. That step had to be done as well to solve this problem.

Of course all of this may be due to inexperience on my part with using SSL on a Drupal site. But I'm doing the best I can and the solutions to these situations are in no way obvious to me.

Obviously this is a MAJOR problem. It is making it to where I don't feel comfortable with any setting to use SSL pages so we can have credit card ordering on the site instead of only giving people the PayPal option. It has made setting up SSL an absolute nightmare. I thought I had it set up as needed to solve this, but I just now noticed that once people are on https:// , they don't ever leave being on https:// and that is causing the problems with the social media elements of the site.

If I can't set up SSL and credit card ordering to work properly, then that's a potential deal-killer for using Drupal at all for any site requiring this functionality. It has only come up as an issue with one site I manage so far as everyone else has been fine with using PayPal only for their stores. But now another site I manage is wanting to add SSL/credit card ordering, so I really need to get this matter figured out. It should not be this difficult to get this set up to work properly and has been a source of considerable frustration that I've spent MANY hours trying to diagnose. I have it narrowed down to a problem with how the cookie/session data is passed between http:// and https:// pages, but am not skilled enough with coding to know how to fix it. The only way I've been able to fix it is to change the module settings as detailed above, but that is then causing the problem with the social media elements of the site we want to include.

Another aspect of the session/cookie part of the problem: In testing, the matter of whether or not the end user is using www.domain.com or just domain.com impacts whether or not they get the "There are no items in your cart" result when trying to add an item to their cart. But it is inconsistent how that works. I've seen it to where using domain.com works while www.domain.com doesn't work for one person, but then www.domain.com works while domain.com doesn't work for another person. I'm not sure what determines when the "There are no items in your cart" problem occurs as it relates to this, but this is part of the equation.

Any assistance would be *extremely* appreciated.

Comments

wildlife’s picture

I think this is solved.

I *think* I found the solution. On this page:

http://drupal.org/https-information

I looked at this paragraph:

If you want to support mixed-mode HTTPS and HTTP sessions open up
sites/default/settings.php and add $conf['https'] = TRUE;. This enables
you use the same session over HTTP and HTTPS both -- but with two cookies
where the HTTPS cookie is sent over HTTPS only. You will need to use
contributed modules like securepages to do anything useful with this mode,
like submitting forms over HTTPS and so on. While your HTTP cookie is
still vulnerable to all usual attacks, a hijacked insecure session cookie
can only be used to gain authenticated access to the HTTP site. It will
not be valid on the HTTPS site. Whether this is a problem or not depends
on the needs of your site and the various module configurations. For
example, if all forms are set to go through HTTPS and your visitors can
see the same information as logged in users then this is not a problem.

I had never seen that before so I tried adding that line to the settings.php file. The person that was experiencing the problem with adding items to their cart said it worked after that. So now I can have all my regular pages using http:// and all store related pages using https:// with the Secure Pages module settings set up as I thought they should be.

So that part is OK now.

I still can't get the Facebook Share button to work on an https:// page without causing that warning about insecure items coming up. I was able to get all the other social media elements on the page to work by changing the URLs they were calling to generate themselves from http:// to https://

bisonbleu’s picture

ah... finally, some meaningful information. Thanks!

adster13’s picture

I'm having this exact issue and I already have $conf['https'] = TRUE; set in my settings.php.

It's really hard for me to troubleshoot because I haven't been able to reproduce the error, but every now and then I get customers complaining that their cart is empty, then when they go back to the product page (http) it shows that their items are in the cart.

EDIT: sorry realised this is for version 6. I'm running version 7

shahidbscs’s picture

This did the trick $conf['https'] = TRUE; to keep user session on.

To also fix https session along with www and without www I added preference to .htaccess.
# Redirect all request to without www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ http%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]

So now we can keep session alive using all kind of user request like
http://
https://
http://www.
https://www.