Jump to content
Latest News: (loading..)
eeto

Enabling SSL breaks customer login in old installation

Recommended Posts

Hi.

I've got a problem with an ancient osCommerce installation which I believe is MS2. It's old and creaky, but it's been at least functional for a very long time. Now I ran into big problems when I tried to get our new SSL certificate working with this installation. I can get it to work alright, different browsers tell me that the site is secure. The problem is that when SSL works, customers can't log in. An attempt to login only directs the user back to the login page with no error message. Trying to use a wrong password does result in a password / user mismatch error, though.

I know this version of osCommerce is very old, but updating is a pain and we're currently planning on building a new shop from the ground up. We'd just need to get SSL working for however long it takes for us to get a brand new site up and running.

 

Here's what I have in my catalog's configure.php right now. This works, customers can log in ok, but SSL is off.

define('HTTP_SERVER', 'http://www.mydomainhere.com'); // eg, http://localhost - should not be empty for productive servers
define('HTTPS_SERVER', 'https://www.mydomainhere.com'); // eg, https://localhost - should not be empty for productive servers
define('ENABLE_SSL', false); // secure webserver for checkout procedure?
define('HTTP_COOKIE_DOMAIN', '.mydomainhere.com');
define('HTTPS_COOKIE_DOMAIN', '.mydomainhere.com');
define('HTTP_COOKIE_PATH', '/shop/');
define('HTTPS_COOKIE_PATH', '/shop/');
define('DIR_WS_HTTP_CATALOG', '/shop/');
define('DIR_WS_HTTPS_CATALOG', '/shop/');


This is how I tried to get it to work. Site appears secure, login breaks.

define('HTTP_SERVER', 'https://www.mydomainhere.com'); // eg, http://localhost - should not be empty for productive servers
define('HTTPS_SERVER', 'https://www.mydomainhere.com'); // eg, https://localhost - should not be empty for productive servers
define('ENABLE_SSL', true); // secure webserver for checkout procedure?
define('HTTP_COOKIE_DOMAIN', '.mydomainhere.com');
define('HTTPS_COOKIE_DOMAIN', '.mydomainhere.com');
define('HTTP_COOKIE_PATH', '/shop/');
define('HTTPS_COOKIE_PATH', '/shop/');
define('DIR_WS_HTTP_CATALOG', '/shop/');
define('DIR_WS_HTTPS_CATALOG', '/shop/');

With the SSL configuration above osCsid also seems to stay in the URLs. Refreshing the page doesn't do anything to it. If I manually delete the automatically appearing osCsid from the page url and load up login.php by itself, login works.

I also noticed that if I login as a customer using the non-SSL configuration and then log out and switch to the configuration that enables SSL, I can log in again as long as the old cookies are present. If I erase the cookies, osCsid appears in the address bar and login breaks.

I'm not really familiar with SSL certificates. All I know is that this is from GeoTrust and the domain matches (www. included) with this site. But I guess the certificate itself is not the problem, since it does appear to work.

 

Here are my settings from the admin side:

Force cookies = false (setting this to true only gives the osC error page about enabling cookies)
Check SSL session ID = true (false when SSL is off)
Check user agent = false
Check IP address = false
Prevent spider sessions = true
Recreate session = true

 

In the error log I'm getting a lot of stuff like this. Could this be a part of the problem? The PHP version on the server is 5.3.29, I thought it's 5.4 that is incompatible?

PHP Deprecated:  Function session_is_registered() is deprecated
PHP Deprecated:  Function session_register() is deprecated
PHP Deprecated:  Function session_is_registered() is deprecated
PHP Deprecated:  Function eregi() is deprecated

 

Any ideas? Any help would be appreciated, I've googled for hours without finding a solution.

Thanks.

Share this post


Link to post
Share on other sites

Change the cookie domain lines to

define('HTTP_COOKIE_DOMAIN', '.www.mydomainhere.com');
define('HTTPS_COOKIE_DOMAIN', '.www.mydomainhere.com');

Also, you have ssl enabled for the whole site, which is correct, but many old shops are not able to work in full ssl mode without changes. Though that should just cause the page to shown as not secure.

The Recreate session can cause this sort of problem so try turning it off.

The errors are showing the server is running a php version that is not completely compatible with your code. Depending upon the failures, that may or may not be an issue.

Share this post


Link to post
Share on other sites

Thanks for your answer, Jack.

I don't think I noticed anything different with the added www. in the cookie domain...

I tried enabling SSL and making both HTTP and HTTPS servers the same (https://www.mydomainhere.com) again. This is the only way my site appears secure in browsers, since otherwise page links still begin with http:// and the login page only appears half-secure in Chrome, for example. I guess securing only parts of the site would be ok, but I don't know how to fully make that happen. The best I can manage is to make Firefox say the site is secure, I guess it's just not as strict as Safari and Chrome.

I tried disabling Recreate Session. This makes login work again on the fully secured site, but only if the osCsid is not present in the address bar. OsCsid hangs around for a few clicks if I clear the browser cache and I visit the site again. The problem is that it's also in the address bar if one of those first clicks happens to take me to the login page, in which case an attempt to log in does nothing. Clicking on other pages a few times corrects this, which seems odd. And now that I tried once again, it seems that osCid hangs around forever even after logging in. Most confusing!

Isn't leaving Recreate Session false unsafe, since it can make customers see each other's accounts in worst case scenarios? It happened to me once when I first set this site up way, way back in 2006. Does setting Check user agent to true stop that from happening?

I guess I should probably just forget about securing the full site (although it seems to be so close to working) and just focus on how to secure the account and checkout parts of the site.

Share this post


Link to post
Share on other sites

Ah, apparently it's unsecure forms that are stopping the checkout and login pages from appearing secure.

Share this post


Link to post
Share on other sites

It's not a very elegant solution, but I think I got the site's SSL securing part working well enough that we can let it be and hope for the best while we continue to plan our new site. Only checkout and user account pages are now secured, and they have a big friendly green lock in the address bar in Chrome now that I changed a line in search.php from

$info_box_contents[] = array('form' => tep_draw_form('quick_find', tep_href_link(FILENAME_ADVANCED_SEARCH_RESULT, '', 'NONSSL', false), 'get'),

to

$info_box_contents[] = array('form' => tep_draw_form('quick_find', tep_href_link(FILENAME_ADVANCED_SEARCH_RESULT, '', $request_type, false), 'get'),

I don't really know what I'm doing here, but it seems to work.

The only problem that remains is that I need to set Recreate Sessions to false to ensure that customers can always log in. Otherwise, if osCsid remains in the address bar, login fails, every time. I'm a bit scared of leaving the setting false. Getting mixed up sessions between users is about the most unprofessional thing that can happen in my opinion...

Share this post


Link to post
Share on other sites

The change you made for the NONSSL is the correct way to do it. In older shops there is generally more than one such form so you may need to change other files.

Having the recreate session is not less secure. It's purpose was to change the session ID for checkout in case the session ID became known, which was common in the early history of oscommerce.  That is unlikely to happen now as long as you have prevent spiders set to true and you are not using the servers tmp directory (see the cache and sessions settings). The session ID will always appear when first visiting a site and may stick around in old shops. If you install one of the url rewriters (Ultimate SEO or SEO 5), that won't happen.

Share this post


Link to post
Share on other sites

Jack I have the same problem where I had an ssl certificate and secure site for only the login and cart/checkout pages.  Now I had to get the whole site secure because my images were being used in ebay as well and not secure for chrome users. My hosting site took care of that and now it fails on the login and loading the cart processes.  Basically we are dead in the water and once this is fixed we will be redoing the site from the ground up as well.   

Can you clarify what changes I need to do to get everything secure AND the login and cart to work?  I see that you told eeto that if ssl is enabled for the whole site, that the older sites may not work in full ssl mode and need changes. This seems to be my problem.  I am unclear on what you were telling eeto to do. Do I need to change my catalog's configure.php by setting the enable ssl from false to true? Can you please give me a step by step?

 

Share this post


Link to post
Share on other sites

Stefanie - Yes, you need to change the enable ssl to true and make the changes Rainer mentioned. If that doesn't fix it, you will need to find out what it is your host did. When I said older shops may not work, I didn't mean they would fail to load. I just meant they might get secure warnings in browsers because of the way they are coded.

Share this post


Link to post
Share on other sites

So my server hostmonster supposedly made a change to cover my entire site as an ssl, which I thought I had covered all along but looking at chrome it was not. There was not a "padlock" icon. Only a couple of pages were securely set up: the login and the checkout process.  My images were not secure when pulled into ebay.  So they said wait a minute and did something and try "it now" - after a couple of tries,  all ok on ebay. Now I cant get a customer logged in or they cannot put anything into the cart.

Of course no one on the hostmonster help desk knows what was done or why it won't work the way it should. I can get a restore done to put it all back but that would be less than optimal.  If I knew an easy way to find the places the http is hard coded then I would fix them all but I am not sure how to find them.  I see code in a detail page of mine where it gives the message about the site name "was loaded over a secure connection, but contains a form that targets an insecure endpoint" I am  unsure where this code is even coming from.    

I have been fiddling with the include/config.php file and I find that if I change it- it changes itself back. 

Original file. Include config.php 

 define('HTTP_SERVER', 'http://www.mysite.com');
  define('HTTPS_SERVER', 'https://www.mysite.com');
  define('ENABLE_SSL', true);
  define('HTTP_COOKIE_DOMAIN', 'www.mysite.com');
  define('HTTPS_COOKIE_DOMAIN', 'www.mysite.com');
  define('HTTP_COOKIE_PATH', '/');
  define('HTTPS_COOKIE_PATH', '/');
  define('DIR_WS_HTTP_CATALOG', '/');
  define('DIR_WS_HTTPS_CATALOG', '/');
  define('DIR_WS_IMAGES', 'images/');
  define('DIR_WS_ICONS', DIR_WS_IMAGES . 'icons/');
  define('DIR_WS_INCLUDES', 'includes/');
  define('DIR_WS_BOXES', DIR_WS_INCLUDES . 'boxes/');
  define('DIR_WS_FUNCTIONS', DIR_WS_INCLUDES . 'functions/');
  define('DIR_WS_CLASSES', DIR_WS_INCLUDES . 'classes/');
  define('DIR_WS_MODULES', DIR_WS_INCLUDES . 'modules/');
  define('DIR_WS_LANGUAGES', DIR_WS_INCLUDES . 'languages/');

  define('DIR_WS_DOWNLOAD_PUBLIC', 'pub/');
  define('DIR_FS_CATALOG', '/home/myname/public_html/');
  define('DIR_FS_DOWNLOAD', DIR_FS_CATALOG . 'download/');
  define('DIR_FS_DOWNLOAD_PUBLIC', DIR_FS_CATALOG . 'pub/');

  define('DB_SERVER', 'localhost');
  define('DB_SERVER_USERNAME', myname_osc01');
  define('DB_SERVER_PASSWORD', 'xxxxx');
  define('DB_DATABASE', 'myname_osc01');
  define('USE_PCONNECT', 'false');
  define('STORE_SESSIONS', 'mysql');
  //define('FEATURED_PRODUCTS_DISPLAY',true);

First I found that this statement: (Line 3)

define('ENABLE_SSL', true);

if it is changed to false, it changes itself right back. So the server is overriding my file.  I don't even have to open the page, the change is made as soon as I load it onto the server. permissions must be set to 555 on this file.

Same is true of this statement: (Line 1)

define('HTTP_SERVER', 'http://www.mysite.com');

when I change to https://www.mysite.com'):

it changes itself back as well....

 

 So I see that they have mucked up the works...  I may have to have them restore everything unless someone can figure out what they did and undo it.

In the admin area: include/config.php has

 define('HTTP_SERVER', 'https://www.mysite.com');

  define('HTTP_CATALOG_SERVER', 'https://www.mysite.com/');

  define('HTTPS_CATALOG_SERVER', 'https://www.mysite.com');

 

I have a test system built in as a subdirectory and it does allow a login to occur but the shopping cart will not add.

  define('HTTP_SERVER', 'http://www.mysite.com');
  define('HTTPS_SERVER', 'https://www.mysite.com');
  define('ENABLE_SSL', true);
  define('HTTP_COOKIE_DOMAIN', 'www.mysite.com');
  define('HTTPS_COOKIE_DOMAIN', 'www.mysite.com');
  define('HTTP_COOKIE_PATH', '/ostest/');
  define('HTTPS_COOKIE_PATH', '/ostest/');
  define('DIR_WS_HTTP_CATALOG', '/ostest/');
  define('DIR_WS_HTTPS_CATALOG', '/ostest/');
  define('DIR_WS_IMAGES', 'images/');
  define('DIR_WS_ICONS', DIR_WS_IMAGES . 'icons/');
  define('DIR_WS_INCLUDES', 'includes/');
  define('DIR_WS_BOXES', DIR_WS_INCLUDES . 'boxes/');
  define('DIR_WS_FUNCTIONS', DIR_WS_INCLUDES . 'functions/');
  define('DIR_WS_CLASSES', DIR_WS_INCLUDES . 'classes/');
  define('DIR_WS_MODULES', DIR_WS_INCLUDES . 'modules/');
  define('DIR_WS_LANGUAGES', DIR_WS_INCLUDES . 'languages/');

  define('DIR_WS_DOWNLOAD_PUBLIC', 'pub/');
  define('DIR_FS_CATALOG', '/home/myname/public_html/jimtest/');
  define('DIR_FS_DOWNLOAD', DIR_FS_CATALOG . 'download/');
  define('DIR_FS_DOWNLOAD_PUBLIC', DIR_FS_CATALOG . 'pub/');

  define('DB_SERVER', 'localhost');
  define('DB_SERVER_USERNAME', myname_mynametest');
  define('DB_SERVER_PASSWORD', xxxxx');
  define('DB_DATABASE', 'myname_osc02');
  define('USE_PCONNECT', 'false');
  define('STORE_SESSIONS', 'mysql');
  //define('FEATURED_PRODUCTS_DISPLAY',true);

Of course no one on the hostmonster help desk knows what was done or why it won't work the way it should. I can get a restore done to put it all back but that would be less than optimal.  If I knew an easy way to find the places the http is hard coded then I would fix them all but I am not sure how to find them.  I see code in a detail page of mine where it gives the message about the site name "was loaded over a secure connection, but contains a form that targets an insecure endpoint" I am  unsure where this code is even coming from.  Something to do with the form name="cart_quantity.php" and product_info.php 

I also have these statements on this same page that may be in conflict.  I think it was a way to make some image not show up but create a space. I cannot get the code I copied to show up here for some reason.  I see it when I do an inspect but it won't copy to here correctly.

<td><img src="images/pixel_trans.gif" border="0" alt="" width="100%" height="10"></td>

Well any help would be appreciated and if it were not for this ebay problem, I would have left well enough alone and thank you in advance. Stefanie

 

 

Edited by wHiTeHaT
removed credentials

Share this post


Link to post
Share on other sites

First, you posted the credentials for your database. You need to change the actual ones now or risk a hacker getting in. You can request that be removed from this thread by contacting a moderator.

As for the configure file, you posted the original and the one for the test shop but not the current one, which is all that matters. But anywhere in it where you see http://www.mysite.com', it needs to be changed to https://www.mysite.com.

It's difficult to say what your host did to cause this but most hosts will only change the .htaccess file when making a change for ssl, if that. They almost never edit the configure file. To use an ssl for the full site, you need to have both the roots .htaccess file and the shops configure file changed. 

 

Share this post


Link to post
Share on other sites

Jack, I don't see where I posted my credentials.  I changed the name of my site.  How do we contact moderators? I put in the configure file I thought with the substitutions of the mysite in it.

I did make the change to https://www.mystite  and  it is being overriden some how and my changes aren't staying the way I changed them.  They immediately change back online to what they were. 

I have no .htaccess due to php code being to old. so it is defaulting to the v 5.2 in order to run at all  I am on RC V22.RC2 version.  I don't know what they did to my site to make it all "secure" no one there knows what the guy did.   I will try to talk to them again and get an answer.

Share this post


Link to post
Share on other sites

These lines of code are where the bad http: comes in:

  This is the code from product_info.php about line 230.


        if (isset($cart->contents[$HTTP_GET_VARS['products_id']]['attributes'][$products_options_name['products_options_id']])) {
          $selected_attribute = $cart->contents[$HTTP_GET_VARS['products_id']]['attributes'][$products_options_name['products_options_id']];
        } else {
          $selected_attribute = false;
        }

translates to this in the inspect feature

http://www.mysite.com/product_info.php?cPath=21_302&amp;products_id=27557&amp;action=add_product&amp;osCsid=lm7dqnn73krtkk5m53ljar76r1

So do I change this :    contents[$HTTP_GET_VARS

to this:                          contents[$HTTPS_GET_VARS

Share this post


Link to post
Share on other sites

No, $HTTP_GET_VARS has nothing to do with whether http: or https: is used.

A moderator changed your post to hide your database information, but you should still change your DB user password, at a minimum.


If you are running the "official" osC 2.3.4 or 2.3.4.1 download, your installation is obsolete! Get the latest community-supported responsive "Edge" release

Share this post


Link to post
Share on other sites

So are you trying to have the entire store placed under SSL (https), or just a few sensitive pages? If your store is way old (certainly 2.2), I'm not sure it's possible to turn on SSL for the entire store (setting all http to https in the configuration files, as well as enabling SSL). You may need to find and edit some code to prevent hard-coded http:.. You should download a copy of your store to your PC (you should have a backup, anyway) and use a tool like grep (Linux) or findstr (Windows) to search for "http:" in all files, and decide whether to change them to https:. Most links are generated with tep_href_link(), which includes a flag for SSL required, non-SSL, or use the current page's SSL. One or more of those might need to be changed from non-SSL to SSL. Note that for a store that old, going through that much work to get 100% SSL probably isn't worth it -- better to upgrade to 2.3.4BS Edge. You might like it enough to keep it as your permanent store.

If you're only trying to get a few standard sensitive pages to display under SSL, that should work for 2.2. Maybe you have an add-on or something pulling in http: URLs. Presumably you have looked at the page HTML in your browser and have narrowed down the area where the offending link is?

It's also possible that your SSL certificate was issued for a different domain than you are using in the store, such as mystore.com instead of the www.mystore.com you use. That would be simplest to fix by changing the configuration files to the new domain (if it's not a wildcard SSL cert).


If you are running the "official" osC 2.3.4 or 2.3.4.1 download, your installation is obsolete! Get the latest community-supported responsive "Edge" release

Share this post


Link to post
Share on other sites

I was under the impression that my store was already ssl as it only effected a couple of pages and those had some ssl code in them already. Things like the login and checkout.  Then I needed my image directory to be ssl compliant for pulling the images into ebay.

So hostmonster made a change and now the whole thing is ssl except a couple of things  being in conflict on the product description page and the login stopped working and the cart stopped working. If I tell you the name of the store and to go to the detail page where you add to cart, can you see it what I am talking about? It has the problem in chrome.

If I upgrade to 2.3.4 bs edge, the last time I tried it I think, it was a total new install right ? I could not do it because the php code was still too old. ???

 

Share this post


Link to post
Share on other sites

I found a clue to what they did:

Here's a problem I had a while back. They stopped supporting my PHP and my store virtually shut down. Not able to open it at all.   Finally after many days, they fixed it by removing the .httaccess file completely.This caused the site to default to the older version. All good - everything worked again.  

Now they added an .httaccess file back in as I knew I was not supposed to have one and the date it was added was when this change took place. it looks like this:

RewriteEngine On

RewriteCond%{SERVER_pORT} 80

RewriteRule ^(.*)$ https://mysitename.com/$1 [R=301,L]

Share this post


Link to post
Share on other sites

I got my passwords changed.  Sorry about that.

Here are my two files, one config.php for production and one for the admin side. If you need to see my test site which does let me log in but still not add to the cart, I can give you that.

production site
includes/configure.php
<?php
  define('HTTP_SERVER', 'http://www.mysite.com');
  define('HTTPS_SERVER', 'https://www.mysite.com');
  define('ENABLE_SSL', true);
  define('HTTP_COOKIE_DOMAIN', 'www.mysite.com');
  define('HTTPS_COOKIE_DOMAIN', 'www.mysite.com');
  define('HTTP_COOKIE_PATH', '/');
  define('HTTPS_COOKIE_PATH', '/');
  define('DIR_WS_HTTP_CATALOG', '/');
  define('DIR_WS_HTTPS_CATALOG', '/');
  define('DIR_WS_IMAGES', 'images/');
  define('DIR_WS_ICONS', DIR_WS_IMAGES . 'icons/');
  define('DIR_WS_INCLUDES', 'includes/');
  define('DIR_WS_BOXES', DIR_WS_INCLUDES . 'boxes/');
  define('DIR_WS_FUNCTIONS', DIR_WS_INCLUDES . 'functions/');
  define('DIR_WS_CLASSES', DIR_WS_INCLUDES . 'classes/');
  define('DIR_WS_MODULES', DIR_WS_INCLUDES . 'modules/');
  define('DIR_WS_LANGUAGES', DIR_WS_INCLUDES . 'languages/');

  define('DIR_WS_DOWNLOAD_PUBLIC', 'pub/');
  define('DIR_FS_CATALOG', '/home/xxxxxxx/public_html/');
  define('DIR_FS_DOWNLOAD', DIR_FS_CATALOG . 'download/');
  define('DIR_FS_DOWNLOAD_PUBLIC', DIR_FS_CATALOG . 'pub/');

  define('DB_SERVER', 'localhost');
  define('DB_SERVER_USERNAME', 'xxxxxxxx');
  define('DB_SERVER_PASSWORD', 'xxxxxxxx');
  define('DB_DATABASE', 'xxxxxxx');
  define('USE_PCONNECT', 'false');
  define('STORE_SESSIONS', 'mysql');
  //define('FEATURED_PRODUCTS_DISPLAY',true);
?>
permissions: 755
production admin includes/configure.php contains this
 <?php

  define('HTTP_SERVER', 'https://www.mysite.com');
  define('HTTP_CATALOG_SERVER', 'https://www.mysite.com/');
  define('HTTPS_CATALOG_SERVER', 'https://www.mysite.com');
  define('ENABLE_SSL_CATALOG', 'true');
  define('DIR_FS_DOCUMENT_ROOT', '/home/xxxxxx/public_html/');
  define('DIR_WS_ADMIN', '/storeman/');
  define('DIR_FS_ADMIN', '/home/xxxxxx/public_html/storeman/');
  define('DIR_WS_CATALOG', '/');
  define('DIR_FS_CATALOG', '/home/xxxxxx/public_html/');
  define('DIR_WS_IMAGES', 'images/');
  define('DIR_WS_ICONS', DIR_WS_IMAGES . 'icons/');
  define('DIR_WS_CATALOG_IMAGES', DIR_WS_CATALOG . 'images/');
  define('DIR_WS_INCLUDES', 'includes/');
  define('DIR_WS_BOXES', DIR_WS_INCLUDES . 'boxes/');
  define('DIR_WS_FUNCTIONS', DIR_WS_INCLUDES . 'functions/');
  define('DIR_WS_CLASSES', DIR_WS_INCLUDES . 'classes/');
  define('DIR_WS_MODULES', DIR_WS_INCLUDES . 'modules/');
  define('DIR_WS_LANGUAGES', DIR_WS_INCLUDES . 'languages/');
  define('DIR_WS_CATALOG_LANGUAGES', DIR_WS_CATALOG . 'includes/languages/');
  define('DIR_FS_CATALOG_LANGUAGES', DIR_FS_CATALOG . 'includes/languages/');
  define('DIR_FS_CATALOG_IMAGES', DIR_FS_CATALOG . 'images/');
  define('DIR_FS_CATALOG_MODULES', DIR_FS_CATALOG . 'includes/modules/');
  define('DIR_FS_BACKUP', DIR_FS_ADMIN . 'backups/');
  define('DB_SERVER', 'localhost');
  define('DB_SERVER_USERNAME', 'xxxxxx');
  define('DB_SERVER_PASSWORD', 'xxxxxx');
  define('DB_DATABASE', 'xxxxx');
  define('USE_PCONNECT', 'false');
  define('STORE_SESSIONS', 'mysql');

 

Share this post


Link to post
Share on other sites

You need to change this line

define('HTTP_SERVER', 'http://www.mysite.com');

to this

define('HTTP_SERVER', 'https://www.mysite.com');

 

Share this post


Link to post
Share on other sites
18 hours ago, jimsmega said:

Now they added an .httaccess file back in as I knew I was not supposed to have one and the date it was added was when this change took place.

Eh? You normally do have an .htaccess file to control many things about your site. Much of any SEO you do is processed there, to rewrite incoming SEO-format URLs to something the program can understand. What the one they gave you only does is force https usage on all incoming requests. The second line "arms" the redirect if the incoming request is http (port 80), and the third line bounces the request back to the browser with "use this address instead" (301 status). While that is helpful for old bookmarks and such that are still http, you need to do a lot more things, such as changing all http to https in the configuration files. Your store is so old that you might also need to manually fix some code that is hard coded to specify http instead of https.

Don't depend on your host's "support"... it's evident that they're not very good, and the probably know nothing about osC, either. Either learn this stuff forwards and backwards yourself, or pay someone to do it for you.


If you are running the "official" osC 2.3.4 or 2.3.4.1 download, your installation is obsolete! Get the latest community-supported responsive "Edge" release

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

×