Jump to content
mrsmarter

http links still show up on SSL page -> href_tep_link problem?

Recommended Posts

Hi all,

first time forum user here, so please slap my wrist *gently* for any mistakes I may make posting here. More about me in upcoming posts. Meanwhile:

I have recently become in charge of some sites, and I am generally upgrading and fixing stuff. So, I was to switch this OSCommerce site from http to https and I came across this weird problem...

-The web server redirects http requests to https -> check
-/catalog/includes/configure.php in the server has define('ENABLE_SSL', true) -> check

Now catalog pages load through https, and are redirected to https://themselves just fine when loaded through http, and all security warnings in browsers are gone (search form 'action' attribute, checkout and shipping pages links all have their https in place). So far, so good, but I noticed ALL other links on a given catalog page are still 'http'. They're sure redirected to https, so this is maybe *relatively* minor, but it shouldn't happen in the first place, should it?

Having a look at the catalog HTML proper I see ' ...
is obviously working, but all 'http' links on catalog pages seem to be generated through href_tep_link in includes/functions/general.php, in which function body I see similar code, but unlike its cousin above it always seems to output http instead of https...

So, before I get hands-on recoding anything unnecessarily, may I be missing anything obvious, in configuration or otherwise, here?

Thanks in advance,

Share this post


Link to post
Share on other sites

It is usually recommended that you change the first line in your configure.php file to https:// as well so it's like this...have you tried that?

  define('HTTP_SERVER', 'https://www.yoursite.com');
  define('HTTPS_SERVER', 'https://www.yoursite.com');
  define('ENABLE_SSL', true);

Dan

Share this post


Link to post
Share on other sites

No, I haven't. While I see how this would 'fix' the situation with these links, isn't there a reason why we have HTTP_SERVER and HTTPS_SERVER? Besides, once HTTPS works as it should, I would like to re-enable normal HTTP on the server so https-impaired users are not locked out.

Share this post


Link to post
Share on other sites
42 minutes ago, mrsmarter said:

I would like to re-enable normal HTTP on the server so https-impaired users are not locked out.

I wouldn't recommend that...these days browsers just warn about it and frighten customers away........can users actually turn off https? and if so, why would you want too?

Dan

Share this post


Link to post
Share on other sites
1 hour ago, mrsmarter said:

isn't there a reason why we have HTTP_SERVER and HTTPS_SERVER? Besides, once HTTPS works as it should, I would like to re-enable normal HTTP on the server so https-impaired users are not locked out.

That wasn't the reason.  Traditionally it was more expensive to serve HTTPS pages (in terms of server resources).  So servers were configured to avoid it. 

Also, shared hosting would often share the SSL across sites.  So the HTTPS_SERVER might have been a different domain than the HTTP_SERVER. 

Now the standard is to make the whole site HTTPS, but osCommerce still has the original configuration.  Eliminating that is on the list of things to do for Phoenix, but I'm not working on it yet. 

Setting the HTTP_SERVER to match the HTTPS_SERVER is the near term workaround. 

I don't know of any client circumstance where HTTP works but HTTPS does not.  Client browsers can all handle HTTPS as far as I know.  And if one couldn't, the user would not be able to register, log in, or check out.  Because all of those tasks require HTTPS_SERVER.  So unless you are willing to make the whole site http, you can't support an "https-impaired" user anyway. 

 


Always back up before making changes.

Share this post


Link to post
Share on other sites
44 minutes ago, Dan Cole said:

I wouldn't recommend that...these days browsers just warn about it and frighten customers away........can users actually turn off https? and if so, why would you want too?

I don't mean to disable https, but it's forced on the users now while testing, and forcing stuff on users is generally not nice. The point is to restore normal http use as a fall-back after enabling https and switching to it as the default, up-to-date connection protocol, once I iron out all the glitches.

People who still connect to websites through http nowadays will more than likely not be able (or willing!) to use https from their side, and have seen a gazillion warnings about the use of https. It's no extra work to support them, though, so I see no technically valid reason to lock them out, or push them to update -- I'd be just lazy to replace a perfectly working technology with another instead of adding the new one in parallel. I also think it's more likely we still see a couple more https versions replaced than any further changes to http. You could simply say stability and backwards compatibility still matter to me -- so much IT these days seems to be about leaving stuff (and people!) behind for no reason at all...

Share this post


Link to post
Share on other sites
2 minutes ago, ecartz said:

I don't know of any client circumstance where HTTP works but HTTPS does not.  Client browsers can all handle HTTPS as far as I know.  And if one couldn't, the user would not be able to register, log in, or check out.  Because all of those tasks require HTTPS_SERVER.  So unless you are willing to make the whole site http, you can't support an "https-impaired" user anyway. 

Sorry, you posted while I was composing my own reply...

A circumstance? When the user is not in control of the system they use (no fancy update to install!) and their browser does not support the current server https implementation, or https at all. I test stuff like that all the time, and except for really sensitive information I have no problem making whole sites accessible through both http and https.

OSCommerce has worked flawlessly in http mode so far, so requiring HTTPS_SERVER to register, log in, or check out seems pretty artificial to me... Wouldn't it be easy enough to change tep_href_link so it simply generates links defaulting to match the current connection protocol, whatever it is? Any reason why this would be a bad idea?

Thank you both for your replies,

Share this post


Link to post
Share on other sites
21 minutes ago, mrsmarter said:

requiring HTTPS_SERVER to register, log in, or check out seems pretty artificial to me... Wouldn't it be easy enough to change tep_href_link so it simply generates links defaulting to match the current connection protocol, whatever it is? Any reason why this would be a bad idea?

I guess the short answer is...its a security issue.

Dan

Share this post


Link to post
Share on other sites

Wouldn't it be more of a security issue that a page served over https links to other pages of the site through http, hoping that the server will take care of that automagically, or that HTTP_SERVER is set to the same value as HTTPS_SERVER?

Share this post


Link to post
Share on other sites

Using HTTP is always going to be a security issue which is why the change was suggested.  If you don't wish to do that, it's on you.

Dan

Share this post


Link to post
Share on other sites

Sure http is a security issue when sensitive information is transmitted, and that makes https preferable, no questioning that. But that's also why happily mixing them --what OSC I have to take care of would be doing, had I not noticed and asked here-- made me start thinking about this in the first place.

The HTTP_SERVER -> HTTPS_SERVER workaround is fine, and I may use it, thank you. However, I would still like to explore other alternatives to get the same results, so I can compare and ponder. In theory, this idea I had above should let me switch between http and 'full' https via ENABLE_SSL alone, which I think is neat and clean. Now I wished to know if this might have unforeseen consequences, that's all. If you deem it an inferior solution, I'm interested to hear what I'd be doing wrong, other than allowing http, and of course no need to follow up if you're not interested.

Cheers,

Share this post


Link to post
Share on other sites

The only other downside I can think of is the possible impact it might have on your search engine rankings.  It could result in lower/shared rankings or even penalties I really don't know.  When the browsers started throwing up warnings on all none HTTPS pages, most e-commerce folks just jumped on board --- taking the easier, softer way.  Everyone already had SSL certificates so why not.

Good luck in whatever you decide to do.

Dan

Share this post


Link to post
Share on other sites
1 hour ago, mrsmarter said:

if this might have unforeseen consequences

You're bebopping along the internet.  You find an HTTP link to a site.  But you want HTTPS, what do you do?  The typical response is going to be to find another site.  Because the typical user won't think to add an s to the http in the URL to see if it works.  Particularly as browsers often hide the protocol, just showing a lock or not. 

There are far more users who you will lose from search engine rankings or simple browsing than by not having an up-to-date browser.  Elderly browsers mostly appear in intranets with no internet access. 

And beyond that, this would be a core change.  Each time the html_output.php file is updated, you'd have to reapply it. 


Always back up before making changes.

Share this post


Link to post
Share on other sites
Posted (edited)

@mrsmarterA number of years ago, maybe 4 or 5, google decided they wanted all of the sites on the web to start using https for all links. They initially asked that it be done but the response was small. They then decided to enforce it by displaying a non-secure warning in Chrome. But the response was still not as high as they wanted. So they changed Chrome again to display an obvious message saying the page is not secure. It didn't matter that a page didn't have anything that needed to be secured. The message is still displayed. That caused the response they wanted. Web-surfers don't understand that a page not be non-secure even though the web browser says it is. If they see a non-secure warning on the page, many will go away. And, as @Dan Colementioned, they also rank pages differently based on whether it has a secure url or not.  FF is also increasing their warnings as a result.

You can run the site the old way by editing the configure file and removing redirects in the .htaccess file, if present. But you would just be hurting your site since it will cause some visitors to go away.

Edited by Jack_mcs

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×