Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

http warnings with Firefox, Google Chrome,....


HansM

Recommended Posts

Hi,

 

According to several internet sites, Firefox and Chrome and guess more will issue a warning with a red cross as soon as a site has http and requests a login.

So sites will have to go to https (SSL cert) to avoid it.

 

Using OSC 2.3 (Bootstrap an none-Bootstrap version) all links and login pages are going to http so warning issues might come with the browsers.

 

Where to do the fixes in the code and/or the database?

 

Greetings

Link to comment
Share on other sites

@@HansM That's always been the case. They are just going to make it more obvious. Install an ssl certificate and you will be all set. If you don't want to purchase a cert, you can check with your host to see if they offer a shared cert, which should be free.

Support Links:

For Hire: Contact me for anything you need help with for your shop: upgrading, hosting, repairs, code written, etc.

Get the latest versions of my addons

Recommended SEO Addons

Link to comment
Share on other sites

Do shared SSL certificates generally work with PHP applications? I know on my host they don't. Is that something intrinsic, or just a host who won't bother doing the configuration? Note that a shared cert will usually have an odd-looking URL (https://servername.hostname.com/~accountname/...) which will turn off many potential customers. Private SSL certificates are also fairly expensive (and require a dedicated IP address at extra cost), so some hosts are now allowing Let's Encrypt and other free/low cost SSL certs. There still will be an installation charge, even if the cert itself is free.

 

Once you have SSL capability (can put at least part of your site under https), it's trivial to configure osC to use SSL for either certain sensitive pages, or even for the entire store. This is in the two configure.php files.

 

Note that if you have an SSL (https) page, and try to put some non-SSL (http) content on it, different browsers will handle this in different ways. Some will mark each point where there is a conflict, while others may just silently skip that content. So, you have to be careful about banner ads and such which might try to put up non-SSL content on your page. This has always been a concern, but will become more critical as sites move to all SSL all the time. Note that this is a bit different from what the OP is mentioning, where any non-SSL page will be flagged as suspicious (or at least, unsafe) by modern browsers.

Link to comment
Share on other sites

We have a number of sites using our shared ssl and they have worked well for years. But we had one that wanted to use hot-llink protection and that broke the ssl for the site. And I seem to recall there was an addon that had a problem with a shared ssl too. So it isn't for everyone and given the low cost of private certs and the url changing, which may bother customers as mentioned, it is probably not worth it. But for shops that are not yet making a profit and can't afford the private cert, it is a better solution than not having one at all.

Support Links:

For Hire: Contact me for anything you need help with for your shop: upgrading, hosting, repairs, code written, etc.

Get the latest versions of my addons

Recommended SEO Addons

Link to comment
Share on other sites

@@HansM That's always been the case. They are just going to make it more obvious. Install an ssl certificate and you will be all set. If you don't want to purchase a cert, you can check with your host to see if they offer a shared cert, which should be free.

Certs, all is there: Lets Encrypt offers me free Certificates installed via Plesk and automaticaly renewed every xx months. Issue was that osc links hardcoded to http. Looks like Steve mentions the perfect thread to this issue.

Link to comment
Share on other sites

Do shared SSL certificates generally work with PHP applications? I know on my host they don't. Is that something intrinsic, or just a host who won't bother doing the configuration? Note that a shared cert will usually have an odd-looking URL (https://servername.hostname.com/~accountname/...) which will turn off many potential customers. Private SSL certificates are also fairly expensive (and require a dedicated IP address at extra cost), so some hosts are now allowing Let's Encrypt and other free/low cost SSL certs. There still will be an installation charge, even if the cert itself is free.

 

Once you have SSL capability (can put at least part of your site under https), it's trivial to configure osC to use SSL for either certain sensitive pages, or even for the entire store. This is in the two configure.php files.

 

Note that if you have an SSL (https) page, and try to put some non-SSL (http) content on it, different browsers will handle this in different ways. Some will mark each point where there is a conflict, while others may just silently skip that content. So, you have to be careful about banner ads and such which might try to put up non-SSL content on your page. This has always been a concern, but will become more critical as sites move to all SSL all the time. Note that this is a bit different from what the OP is mentioning, where any non-SSL page will be flagged as suspicious (or at least, unsafe) by modern browsers.

Yes, always test on several browser: mozilla based browsers, safari, IE, the default browser in an android,...etc. You might get warning with some browsers if you include with http a remote jpg for example....

Link to comment
Share on other sites

Not solved:

question is: how to change the http calls in the source code, which php pages do have them inside.

 

The problem is that even rewriting http to https does not work since I will see mixed content!

So My OSC version that I took from github is including things like bootstrap with a http request, that should be https.

Also the images:

 

Example:

Mixed Content: The page at 'https://domainname/index.php'was loaded over HTTPS, but requested an insecure script 'http://domainname/ext/bootstrap/js/bootstrap.min.js'. This request has been blocked; the content must be served over HTTPS.

2nd examples: the images then from OSC:

Mixed Content: The page at 'https://domainname/index.php'was loaded over HTTPS, but requested an insecure image 'http://domainname/images/card_acceptance/visa.png'. This content should also be served over HTTPS.

Link to comment
Share on other sites

What is the problem? If you have an SSL certificate, you have two choices. Both involve editing the two configure.php files. If you only enable SSL (admin configure), as well as give "https" for the HTTPS entries, osC will automatically use SSL on sensitive pages (login, etc.). That should clear up your issue with logins under http. You are free to edit code (tep_href_link calls) to add more pages to the "use SSL" list. Or, use "https" for both the HTTP and HTTPS entries in the configure files. There's been some discussion here and there about running a site (or at least, the osC store) entirely under SSL; you'll probably want to read up on it. Everyone will be going that way in the future, as browsers will discourage use of plain http sites, and not just sensitive pages under http.

 

This should leave your vanilla osC installation working correctly, and not mixing http content onto https pages. If you have banner ads or other add-ons, you might have to do some code fixes to use https for some of this content, if it's currently hard coded to use http. It depends on what extras you're using.

 

If you're really still on osC 2.3, that's way obsolete, and you should be migrating to osC 2.3.4BS Edge (community supported responsive version).

 

If you have SSL installed and are still getting http pages even after correctly configuring your store, check to see if your SSL certificate matches the exact domain name you are using. For example, if your cert is for mysite.com, you won't be able to do https://www.mysite.com (only https://mysite.com).

Link to comment
Share on other sites

@@HansM

 

No one said it was going to easy.

 

I had to go through every page of my site when I changed all the files to work on https to change any images and links that were http and change them all to https. I had lots of little images within the product descriptions, but once you know what images are causing the problem it was easy to change those products. It was also possible to change those images to /images/name of image.jpg or what ever and remove the http:// website name.com part. Now whether that is a right way of doing it I have no idea but it did work when I tried it.

 

I also added code into the htaccess file to make sure all http pages were changed to https. The code is in the other thread that I previously posted.

 

Did you read the whole thread and find the link to https://www.whynopadlock.com/. That site was so helpful.

REMEMBER BACKUP, BACKUP AND BACKUP

Link to comment
Share on other sites

I am converting one site from osC 2.3.4 to osC 2.3.4 (BS3 and Edge from github-gburton)

Only thing left is to transfer/convert the whole big catalog to the Edge version, I have to see which database tables I should not copy over. Like the config/admin on the new domain. only the tables with categories, orders etc. But that is out of this topic:-)

 

The SSL certificate i have installed it on www.domain.com and i have the .htaccess rewrite lines to make https from http calls.

But as I said that is a bit closer to the solution but stlil the links to the products are http links, even in Edge.

 

Phil thank you so much, I was not aware (anymore) that configure.php (2 locations) had http/https/secure settings.

Now they look like this: (as you see 2nd line has http instead of https, I will change it and enable SSL I will set it to true)

 define('HTTP_SERVER', 'http://www.int.net');
  define('HTTPS_SERVER', 'http://www.int.net');
  define('ENABLE_SSL', false);
  define('HTTP_COOKIE_DOMAIN', '');
  define('HTTPS_COOKIE_DOMAIN', '');
  define('HTTP_COOKIE_PATH', '/');
  define('HTTPS_COOKIE_PATH', '/');
  define('DIR_WS_HTTP_CATALOG', '/');
  define('DIR_WS_HTTPS_CATALOG', '/');
Steve also thanks! Luckily the web development tools in the browser (chrome and seamonkey) show the warnings(or mixed errors) so it is "easy" to find issues.

Now with all this knowledge I can continue the setup of the new Edge.

I will first make this all waterproof with the default osC database and make a backup. Then the bigger step to get the 3000 articles into the Edge database (p.s. yes I know there is a conversion database script on the gburton git page)

Thanks again all!

Link to comment
Share on other sites

Why are you going through all this manual labor to convert to 2.3.4BS? It includes an SQL script to update a 2.3.4 database to 2.3.4BS. Unless you have done some major customizations, that should do the job for you.

 

Be careful not to confuse the two configure.php files. They (the "catalog" or storefront, and "admin" or back-end) are different! They are not interchangeable.

Link to comment
Share on other sites

Why are you going through all this manual labor to convert to 2.3.4BS? It includes an SQL script to update a 2.3.4 database to 2.3.4BS. Unless you have done some major customizations, that should do the job for you.

 

Be careful not to confuse the two configure.php files. They (the "catalog" or storefront, and "admin" or back-end) are different! They are not interchangeable.

I did export the old 2.3.4. database and imported it in the new BS3 shop, then I did the SQL script to convert it.

after that the layout was still repsonisive but the bootstrap columns were ways too wide and somehow missing images. It looked horrible compared with the default product catalog you get delivered with a clean install.

So the way I managed it now: on the (still) live site I run the (gburton) SQL script. Then I export and import this one in the new subdomain. (2700 products). Now the BS3 layout is looking more normal, still need to fix certain things (working on that). I also installed a payment module, that also works nicely.

I also had to adapt these two table fields in the database table: configuration:

SESSION_WRITE_DIRECTORY and DIR_FS_CACHE(these two will have of course another path compared with the live shop)

So from now I get the more easy issues like " My login page is empty it just shows "Welcome, Please Sign In"

Still working on that one since in the admin->modules->content I see a "login form" already included, but when I edit it I see just 3 input fields without surrounding information to see where the 3 fields are for. If I edit these 3 fields with random text or numbers it does not get stored after a save. The server errorlog shows no errors.

I have two languages installed: dutch and english. In both languages I get the same error. Maybe this addon I used is doing something with the login page....

And yes I have seen these two configure.php files are different :-)

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...