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

We're off topic here but, I did want to mention that a DV cert no longer requires the dedicated IP as cpanel can properly separate domains from only one IP.

Let's get back to the topic.

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?

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.

So, I didn't get a response to the question asked in the first paragraph, but I have just considered this as a possibility, if this path is considered desirable.

At a point after the sessions have been loaded and perhaps after $request_type has been set, you set a session variable to indicate what type of URL was used to access the site. If it were https, then one value, if http another, but in either case the session value is set.

Then, at least when using ZC 1.5.5, there is now a notifier that allows you to pick up on link generation requests, though you would want to also ensure appropriate sequencing with any other plugin that attempts to use that notifier because you want the value to be set as desired before that other observer grabs hold of the data ($connection). Notifier to which I refer is found in includes/functions/html_output.php in the zen_href_link function.

In the new observer, if the session is set to https, then make the $connection variable = 'SSL' regardless of the original/previous request, if not set to https, then leave it alone and use whatever value to which $connection is set (don't modify the value of $connection).

I think that would accomplish the requested task, assuming it is still considered desirable...

I still have a prepared answer to a question I was asked earlier, but not sure if on topic for that one. :)

It may even be desirable to put the session setting value inside of the sessions code such that a visitor sees the session value, but a bot does not... Haven't thought that far through it yet. Awaiting "input". :)

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?

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.

If a site user enters the site via https, they expect that their entire session will be SSL encrypted.
If a site then redirects them back to http, their expectation is violated.

one tall man:

If a site user enters the site via https, they expect that their entire session will be SSL encrypted.
If a site then redirects them back to http, their expectation is violated.

Okay, but, what is your consideration if a site visitor enters the site with http:, but at some point is redirected to https: like say they go to send the site owner a message using contact_us. When they then continue on their merry way, which if looking at product on the site would be via http: should they be "allowed" to return to http: or are you thinking that now that they have stepped "up" they can never step back "down"? (please BTW, that is a metaphorical up/down comparison, I am not saying as a comparison, but more like a logical on/off).

mc12345678:

When they then continue on their merry way

They will continue over https which I have zero problem with.

one tall man:

They will continue over https which I have zero problem with.

Per your design request and the discussion I provide above, no they would not go on/continue on using SSL, because the design proposed met the request: want all pages to be SSL if user entered SSL related webpage to access the site. Therefore, if they accessed the site using http: then the proposed solution would enable https: when it was expected to be used, but would return to http: when not so expected (ie. Product information pages, shopping cart, etc...) if they initially entered an https: uri, all pages onsite would be presented https: until they either logged out or their session expired (left the site for a long time).

To then continue on using SSL for each and every properly coded uri after visiting any page while SSL has been requested is a different solution.

Good thing I didn't go trying to write code today based on your design request, because would be back modifying things again or just letting someone else "correct" the situation.

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?

one tall man:

If a site user enters the site via https, they expect that their entire session will be SSL encrypted.
If a site then redirects them back to http, their expectation is violated.

In this regard I see no benefit to you serving your site as http at all. If your goal is to have people purchase things, then since it only takes a few clicks before they need to use https for login or checkout, you may as well just use https for everything.
Setup for that is simple:

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

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

I am lost in your academic debate and do not have time and resources to read even 10% of what is posted, but I know for certain from my customers' feedback that if they entered my site via https, they expect 100% of their interaction with the site to be SSL encrypted. I understand where they are coming from and have zero problem with their wishes.

If some however want to use http, they should be allowed to do so.

I redirects all to https and see no problem with it

one tall man:

I am lost in your academic debate and do not have time and resources to read even 10% of what is posted, but I know for certain from my customers' feedback that if they entered my site via https, they expect 100% of their interaction with the site to be SSL encrypted. I understand where they are coming from and have zero problem with their wishes.

If some however want to use http, they should be allowed to do so.

You've read and replied to most of it already, so 10% of what remains was less than one word. The discussion was to attempt to provide specific custom design code to address your situation based on the expectations. The cleanest/clearest solution is as DrByte recommended which is to just make the full site https:.

Follow DrByte's recommended modification and it should satisfy those that wish to see a blue lock everywhere.

one tall man:

If some however want to use http, they should be allowed to do so.Neither you are your customer really get to decide. More increasingly, browsers are the culprits declaring that a site is insecure no matter if it is eCommerce or not just because is is using http versus https.

DrByte:

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

To this:
define('HTTP_SERVER', 'https://www.vintageelectronics.ca');
So in summary, if I want to update my site to https only, all I need to do is

1. make the change above, and
2. do a 301 redirect for all http calls to https, to ensure any hardcoded http calls will be redirected to https, right?
   Thanks guys!

Can someone confirm that this is correct please? Thanks guys!

ttfan:

Can someone confirm that this is correct please? Thanks guys!
The action to be taken or perhaps the condition to be in place is described at the following FAQ. There are setups that would be able to operate with just making the change to HTTP_SERVER, but that doesn't mean all can operate that way nor that all things will work with just that change away from a default store. Plus, not all current condition data has been provided. So, stick with the FAQ: https://www.zen-cart.com/content.php?56-how-do-i-enable-ssl-after-i-have-installed-zen-cart

Thank you kindly. :thumbsup:

My second part of the question is not covered though. Will a 301 redirect in .htacess, redirecting all http calls to https, solve the mixed content issue? I know I have quite a few hard-coded images with a http prefix in some of my pages (like EZ pages or defined content pages), so I'm hoping this will fix it?

ttfan:

Thank you kindly. :thumbsup:

My second part of the question is not covered though. Will a 301 redirect in .htacess, redirecting all http calls to https, solve the mixed content issue? I know I have quite a few hard-coded images with a http prefix in some of my pages (like EZ pages or defined content pages), so I'm hoping this will fix it?
No generally speaking an htaccess rule will not affect the mix of content on the page. The htaccess basically processes before the page is loaded and was designed to control access to the site. Mixed content comes from what is presented on the page which occurs after the visitor has been allowed to access the site. Further that "issue" is covered by yet a different FAQ: https://www.zen-cart.com/content.php?185-this-page-contains-both-secure-and-nonsecure-items-%28or-unauthenticated-content-or-connection-partially-encrypted%29