How can I change all links in the store to be https if the site accessed via https?

I looked at the thread https://www.zen-cart.com/showthread....SSL-in-my-site and read the linked manual, then implemented the edits to the configure.php files, but still when opening my site using https:// protocol, the links remain http://

define('HTTP_SERVER', 'http://www.vintageelectronics.ca');
define('HTTPS_SERVER', 'https://www.vintageelectronics.ca');
define('ENABLE_SSL', 'true');

What am I doing wrong?

The instruction that you read relates to how to enable SSL for the pages that are to be considered SSL which include but are not specifically limited to, login, checkout, contact_us, etc...

In order to enable the full site (all pages) to be SSL, then your HTTP_SERVER address should be changed to include https:, and then ENABLE_SSL should be set to false instead of true. When set to true, then the system determines what page(s) should be presented with https: and will use that setting/option instead.

Now, that said, you also need to arrange for visitors to your site to go directly to an https: page, no matter what page they have entered in their URL. That requires either a change in your control panel with your host, or manually adding code/information into an .htaccess file that is at the root of your site. ZC does not require nor provide such a file because it is not seen as necessary, so you may want to work with your host or perform additional research either using the ZC forum search, an outside search engine (that may guide you back to this forum or to another site). There are multiple ways to implement the change with some working "better" than others.

Do be sure before you do all this changing that you can successfully access whatever page(s) you wish to access by typing in https: as part of the page load. You want to be sure that there are no web browser related errors where mixed content would exist on any loaded page (ie. if you have hard coded links that include src="http:... then access the page using https: a browser will typically indicate such mixed content exists).

Ohh and be sure to read/apply the information that DrByte posted about... Very useful and informative.

Quote:

---

Originally Posted by one tall man

but still when opening my site using https:// protocol, the links remain http://

define('HTTP_SERVER', 'http://www.vintageelectronics.ca');
define('HTTPS_SERVER', 'https://www.vintageelectronics.ca');
define('ENABLE_SSL', 'true');

What am I doing wrong?

---

Change this:
define('HTTP_SERVER', 'http://www.vintageelectronics.ca');

To this:
define('HTTP_SERVER', 'https://www.vintageelectronics.ca');
(both config files)

That is all.

Note: You will find a bit of debate as to whether define('ENABLE_SSL', 'true/false'); should be true or false. Fact is, with both HTTP_SERVER & HTTPS_SERVER being defined as 'https' this ENABLE_SSL setting becomes a moot point as all pages will be SSL enabled anyway.

Cheers
RodG

Quote:

---

Originally Posted by RodG

Note: You will find a bit of debate as to whether define('ENABLE_SSL', 'true/false'); should be true or false. Fact is, with both HTTP_SERVER & HTTPS_SERVER being defined as 'https' this ENABLE_SSL setting becomes a moot point as all pages will be SSL enabled anyway.

Cheers
RodG

---

... except that having ENABLE_SSL also set to true forces extra session regeneration and different cookie handling. In many cases this won't be problematic, but in some bizarre server configurations setting it to false resolves those odd issues.

Quote:

---

Originally Posted by DrByte

... except that having ENABLE_SSL also set to true forces extra session regeneration and different cookie handling.
In many cases this won't be problematic, but in some bizarre server configurations setting it to false resolves those odd issues.

---

Although I don't quite understand how this could be without having similar issues when an *actual* switch between SSL/NonSSL takes place (IOW, while the HTTP_SERVER' is not 'hhtps') I'm not going to argue about it, at least not with you <g>

It's just counter intuitive (to me) and I'd have expected that if there were going to be problems due to 'bizarre server configurations' it would be when all is set for SSL, but the ENABLE_SSL was set to false.

I shall keep your apparent observations in mind with any future comments I make in this matter.

Cheers
Rod

PS. Would I be wrong in assuming that a future update will do away with the http_server and the enable_ssl setting (and all the associated code) since its just a matter of time before we have no choice other than SSL everywhere anyway?

Quote:

---

Originally Posted by RodG

PS. Would I be wrong in assuming that a future update will do away with the http_server and the enable_ssl setting

---

In v1.5.5 that's already happened in the Admin: https://github.com/zencart/zencart/b...figure.php#L19
Further, in v160 there's no admin configure.php at all, since it simply uses the main /includes/configure.php
It's not fully done-away-with catalog-side yet, but refinements there are anticipated.

I did not want to switch the entire site to SSL.
All I was looking for was for the http://domain/ to have all http:// links, but if arrived at the site via https://domain/ for all links to follow the same and be https:// links. Is that possible? If they were relative links, they would inherit the protocol, would they not?

Quote:

---

Originally Posted by one tall man

I did not want to switch the entire site to SSL.
All I was looking for was for the http://domain/ to have all http:// links, but if arrived at the site via https://domain/ for all links to follow the same and be https:// links. Is that possible? If they were relative links, they would inherit the protocol, would they not?

---

Oye, that's an entirely different action/request. What is expected to occur at say the login page, or checkout? And then again after such page(s)?

The answer to can it be done? Absolutely it could. What is the "advantage"? What is the benefit that you are seeking to gain? Or what problem is trying to be prevented?

I'm wondering, though can't say that I've tried it if you changed your HTTP_SERVER to just //mydomain (dropping the http: and/or https:) how it would respond/react. The whole thing is deeper involved than just those one or two constants, but it makes me wonder.

Quote:

---

Originally Posted by mc12345678

Oye, that's an entirely different action/request. What is expected to occur at say the login page, or checkout? And then again after such page(s)?

The answer to can it be done? Absolutely it could. What is the "advantage"? What is the benefit that you are seeking to gain? Or what problem is trying to be prevented?

---

Very good questions. I can't wait to see the answers :)

Quote:

---

Originally Posted by mc12345678

I'm wondering, though can't say that I've tried it if you changed your HTTP_SERVER to just //mydomain (dropping the http: and/or https:) how it would respond/react. The whole thing is deeper involved than just those one or two constants, but it makes me wonder.

---

This did also cross my mind, especially since it is about the only way that I can think of that would make the OP's request possible,

I wouldn't try it in a million years though - The security implications are *huge*. Just consider the case when (not if) a hacker tries to access the site using "ftp://domain.name:80"

The response will be from the server (port 80), but the FTP client won't render the html/php like a web client - it will show the 'raw' data , and since all URI's will now also be 'ftp' it wouldn't be difficult to have the ftp client load and display the config files complete with DB login details - all in plain text. (normal apache directives and .htaccess rules will no longer apply) ,

Game over.

Admittedly, I've almost certainly oversimplified things here - but the point I'd like to make is that *without* the http/https protocol specifier the opportunity for abuse by other protocols is both huge and unpredictable, so even though what the OP is seeking is possible (using this method) they really *shouldn't*.

Cheers
RodG

Quote:

---

Originally Posted by one tall man

I did not want to switch the entire site to SSL.

---

This is something that many of us don't want.

Unfortunately, this is no longer really our choice - Google is demanding 'SSL everywhere' - and although I object to being dictated to in this manner (and our business can survive without Google), most ecommerce sites can't - So to survive - the future of eCommerce is 'SSL everywhere' regardless of what you and I want.

Quote:

---

Originally Posted by one tall man

All I was looking for was for the http://domain/ to have all http:// links, but if arrived at the site via https://domain/ for all links to follow the same and be https:// links. Is that possible? If they were relative links, they would inherit the protocol, would they not?

---

Yes, it is possible, and yes you are correct about inheriting the protocol - but as I just wrote in a previous post, the security implications of this inheritance are huge.

mc1-8 has suggested how it would be possible (at least in theory) to do what you are seeking, with very little effort or changes, but if this is something that you would like to achieve *without* those risks, things become a lot more difficult. I *know* that this *should* be possible (without the risks). I've even had a few ideas how to make it so, but for each idea I've had so far, a little more thinking has me rejecting the approach as being unworkable for one reason or another. The more I think on it, the more complex the solution becomes (perhaps I'm over thinking it?)

Anyway, possible or not, easy or difficult, as I stated, we don't really have much of a choice these days - it's going to be 'SSL everywhere' - or a store that can't be found, and if it could be found, the warnings about 'insecure' is a nail in the coffin anyway.

Sorry to say, but IMO, you should give up on this idea, bite the bullet (as I have done), and do what Google is demanding us do (even if it is only for the benefit of Google, 'cos they sure aren't doing it for *our* safety).

Cheers
RodG