SSL Issues 2.2.4

We have recently completed our store and thus turned on the 3 SSL options in admin for final testing.



ON - Enable secure connection at checkout (SSL certificate is required to be installed on your server)

ON - Enable secure connection in the administration panel (SSL certificate is required to be installed on your server)

ON - Enable secure connection for authentication, profile and orders pages (SSL certificate is required to be installed on your server)



The following behaviour is procuded:



Shopfront



Sign In:

will not sign in, immediatly kicked out



Shopping:

add products to cart, go to checkout, sign in - drops contents of cart and signs you back out immediatly.



if you add products to cart, go to checkout and REGISTER as a new customer, it will let you through and not drop the cart contents.



Admin



Sign In:



Will not pass login screen. enter your details and press enter, just clears the fields and goes nowhere.



NO ERROR MESSAGES ARE PRODUCED!



We have tried:



clearing browser cache and site cache by deleting cache and complied folders to no avail.



Please help urgently!!

What are your settings in config.local.php for https_host and https_path?

Are your certificates valid for your domain?

What does your PHP error_log file tell you?

[quote name='tbirnseth' timestamp='1324153088' post='127983'] What are your settings in config.local.php for https_host and https_path? Are your certificates valid for your domain? What does your PHP error_log file tell you? [/quote]



settings are fine - i think this is demonstrated by the fact that checkout will work if you register new and dont try and sign in existing



where can i find the php error_log?



I suspect this is more of an underlying error to do with sessions or something, simply highlighted by ssl

error_log varies by host. But most cPanel installations have an Error Log icon in the Logs area. Check with your host.

web host says there is no errors.



Along with our shop, I have since installed a fresh copy of cs with demon data on another domain and tested them both on different computers on different connections with different browsers including, ie, chrome, safari, firefox.



the ONLY browser in which the site always behaves as it should is Safari.



this is becoming a real nightmare after we have done all this work customising it as we want, now this is the only thing holding me up putting it live.

details of fresh copy for others to test and hopefully find out what is going on:



http://discountink.com.au/cs/index.php?



click sign in



username: customer

password: qwerty



ie, firefox, chrome - have been found to work randomly, if they do let you sign in it will only be once. if you do get in, add some things to cart, go checkout then sign out and try signing back in, 100% off the time I tested I didnt get back in a 2nd time, the chances of getting in the first time were 1 in 50.



safari - will just sign in as it should no problems

[quote name='xcomm' timestamp='1324168965' post='128000']

settings are fine [/quote]



Since this is an isolated issue, how do you know your settings are “fine”?

[quote name='The Tool' timestamp='1324337697' post='128102']

Since this is an isolated issue, how do you know your settings are “fine”?

[/quote]



Well


  1. I have set up numerous stores under zencart and xcart in the past without issue
  2. behaviour is fine in safari
  3. theres really only 2 settings in config.local anyway so its not rocket science - extract below:



    $config['http_host'] = 'discountink.com.au';

    $config['http_path'] = '/cs';



    // Host and directory where software is installed on secure server

    $config['https_host'] = 'secure.discountink.com.au';

    $config['https_path'] = '/cs';

Why complicate it by using a subdomain with the same IP (unless of course your SSL is for secure.discountink.com.au).

Have you tried just using discountink.com.au instead?

[quote name='tbirnseth' timestamp='1324341855' post='128112']

Why complicate it by using a subdomain with the same IP (unless of course your SSL is for secure.discountink.com.au).

Have you tried just using discountink.com.au instead?

[/quote] c'mon i'm not a complete idiot, the ssl certificate is for secure.discountink.com.au and it works and has been on the site for years

[quote]c'mon i'm not a complete idiot,[/quote]

Guess you haven't been here much. Just ensuring the obvious isn't being overlooked.

Nothing else to add since I've not seen the behavior before.

about the same problem on my site

checkout step two was hanging with the famous loading box.

disabled my ssl in admin panel to fix this.



in [color=#282828][font=arial, verdana, tahoma, sans-serif]config.local.php js-compression set to false[/font][/color]

inline_compilation set to false

join_css set to false

RESOLVED



It appears cs-cart on some web hosts does not like the http & https URL's to be different. It also appears to prefer you put www. infront of the url.



We have resolved this by purchasing a new ssl certificate in the same url (dropping the secure. prefix)



We will note however that no www prefix and using the secure. https url NEVER presented any issues under: oscommerce, zencart and xcart (our 3 previous platforms for the website) I stand by the fact that this is a cs-cart bug and it should not behave this way, or atleast give some kind of error message when it does.



In our talks with cs-cart they admitted sign in kick-outs have affected some users but they maintain it is a hosting issue, we disagree as our past expeince with our others carts on the same settings have never given any problems.



Having to purchase new ssl certificates or try other web hosts are not ideal solutions.

LMAO!!!



If you have a gas powered lawn mower and you go and buy an electric powered lawn mower, are you going to complain that the electric one doesn't run on gas?

lol, before i upgraded to pro2.2.4 the problem was non existing.

after upgrading to 2.2.4 the problem started.



all on the exact same host! How can that be a hosting problem.



its more like taking your car to the shop for an oil change, and they forgot to tighten the oil drain plug.



The shop says it is the road you are riding on that is responsible for the drain plug to fall out!

[quote name='The Tool' timestamp='1324614975' post='128315']

LMAO!!!



If you have a gas powered lawn mower and you go and buy an electric powered lawn mower, are you going to complain that the electric one doesn't run on gas?

[/quote] what the fuck are you talking about

We're on version 2.2.4 PROFESSIONAL and this is still a problem for us. We have an SSL domain that is not the same as the standard domain (replaced www with secure).



Has a fix been released for this?

@Lima Bean - What specifically is the problem you are seeing? I'm guessing it is a session issue since your 'secure' domain is different than your store. Hence you get a new session when you switch to ssl. It's actually a different domain… Hence a new session_id.

@tbirnseth, yes, the issue is that the secure domain is different to the store, so most probably a new session_id. Is there no fix available for this so that the secure domain can be different to the non-secure domain?

I don't know what they have cooked up, but sessions usually work off of domains so things like test.site.com is different than site.com



Where is the document root for 'secure'? Same location as the base store?