Setting HTTPS=true problem

[gprit]

As a pre requirement to going live I set (both) configure.php files to set HTTPS=true.]
However,once this is done none of the sections of ADMIN work - they return notfound for every .php.

I have taken this up with the hosting company (as I have other websites set in exactly the same way). They say:

"We were investigating whether this could be an issue with the site being on one of our load-balanced servers but this was not the case. I don't know your site well enough to know what is pointing to this URL I'm afraid, it sounds like this may be generated by zencart so you may be able to resolve by just changing a setting in the backend. You could try downgrading Zen cart to a previous version, make sure you backup your site first though"
............and

" From what I can see you have no SSL certificate (third-party) installed for (thegiftshop.tv). Thus, you are using the self-signed shared server URL of (secure-secure.co.uk) using the below link:-

https://web24.secure-secure.co.uk/th...min!/login.php

This is definitely a coding issue, as once you login, you software is rewriting the URL of the login page as:-

http://thegiftshop.tv/thegiftshop.tv...dnk230420fuk84

As you can see, I assume your software turns of HTTPS once logged in, however your software possible via some form of rewriting rule I guess is creating the URL as (http://thegiftshop.tv/thegiftshop.tv/) see the domain is printed twice, making it invalid. Perhaps you need to set the URL path/site path correctly maybe in some file/database within your software to resolve this to just print the domain once, not twice".

I find this difficult to believe - why should it act differently to my other websites? Why should changing HTTPS to = true cause this?

The only difference I am aware of is that the current problem is with zencart 1.5.1, the others (working ok) are 1.3.9

Any thoughts?? thanks

[DrByte]

If you gave it http:// instead of https:// in your configure.php file, then it will of course redirect you to the http:// instead of https://

Remember, when making changes to configure.php, those files are usually set to read-only, so you'll need to make them writable before you can save changes to them.

[gprit]

Well yes I realise that...but https is secure for payments. It seems to be connected somehow with the fact that the host uses a load balancing server, which handles https in a different way.

[DrByte]

Then you need to sort out your https issues with your hosting company, since it seems your issues are server-side, not a Zen Cart issue.

[davidwfanning]

I just solved a couple of SSL problems on my web page and thought I would share my experience. I had two problems. My store would not validate as "pure" SSL (it had non-SSL links somewhere in it), and my store would not "switch" to SSL mode when customers were checking out, etc. Nor was my admin in SSL mode.

The non-SSL items problem turned out to be due to a problem with a single image file in a store template I had purchased for my store. I discovered this problem in the store/includes/templates/CUSTOMTEMPLATE/common/tpl_footer.php file. I changed the link from http:// to
https:// and all was well. I found this problem by running the store though the http:www.whynopadlock.com web page.

The problem with my store not "switching" to SSL mode was MUCH harder to suss out. I have a copy of my web page on my local machine. I make changes to these files and copy the files over to my web page on my domain server via Filezilla FTP. I made the required changes to both the configure.php files to set myself up in SSL mode, but the store just wouldn't switch. It turns out that the configure.php file in store/includes had a file permission of 444, rather than the usual 644. So, even though it LOOKED like I was downloading the changed file from my local machine to the remote machine, the file was not actually being copied!! (No errors in Filezilla, by the way.) Thus the define('ENABLE_SSL', 'true'); was always set to 'false' on the remote machine. Resetting the file permissions and then updating the file worked perfectly.

[RodG]

The non-SSL items problem turned out to be due to a problem with a single image file in a store template I had purchased for my store. I discovered this problem in the store/includes/templates/CUSTOMTEMPLATE/common/tpl_footer.php file. I changed the link from http:// to
https:// and all was well.

Just a suggestion, but if you have a need to re-edit this link, or any others like it, you are far better of to use relative rather than absolute URL's.

For example, instead of

<A HREF="http://yourdomain.com/folder/image.jpg">   
or
<A HREF="https://yourdomain.com/folder/image.jpg"> 

Change it to 
 <A HREF="/folder/image.jpg">

This has three significant benefits:
1) It will work correctly for both secure and non-secure pages.

2) It will alleviate the need for the client's browser to perform another DNS lookup. With only one image, this is no big deal, but if there are dozens of images this can have a measurable effect.)

3) If you ever need to migrate your site to use a different domain name (For example, if you decide to place it somewhere like 'store.youdomain.com') the image(s) will correctly load from the new location.

The only time absolute URL's should be used if if/when the images (or whatever) are being stored on *another* domain entirely.

Cheers
Rod