Expiring shopping carts

[Pneumatus]

Hi guys,

I'm having an issue which i believe to be due to one of our main servers reporting a different time zone to our ssl server causing any order placed to be rejected when you enter the OrderScript perl file on the secure server. Our main server is showing the timezone as BST and has the correct local time, the SSL server is showing GMT and as a result, hasn't adjust the clock making it an hour earlier - this means that regardless of what I set in the cart expiry period, i guess that because the SSL server is ahead in time, the cart doesn't exist or something - is there a possible fix for this or am i barking up the wrong tree?

Regards

[Pneumatus]

Right, both servers are now running on BST but there still appears to be an expiring issue. I have tried deleting everything and starting again on the site but to no avail. I am getting strings in the error.err file along the lines of:

Program = ORDERSCR, Program version = 478 , HTTP Server = Apache/1.3.28 (Unix) mod_ssl/2, Return code = 999 , Date and Time = 2004/08/04 14:14, Internal Errors = Your shopping cart has expired, orders must be completed within 12 hours or they will be automatically cancelled.

The thing I notice straight away is that the time is one hour out - BST hasn't been accounted for - I guess this is a result of using gmtime() in Actinic::GetActinicDate() rather than using localtime().

I'm really confused why the carts are 'expiring' now... can anyone shed any light?

[cdicken]

Have you tried extending the shopping cart expiry period in 'Web | Configure Expiry Periods'?

If you can give me a URL that is experiencing the problem, I can pass this onto the development team.

[Pneumatus]

Hi Chris,

I have upped the expiry period to 12 hours - but this error is appearing as soon as you create a cart.

I'd appreciate if you could get someone to look at it ASAP so i can revert the site back to the Java encryption at least in the hope we may not loose too many more orders.

The site in question is http://www.glowsticksdirect.co.uk/

You should see that when you go to checkout and the site switches to SSL, an error occurs.

[DBurrows]

Im thinking seeing as the time zone was originally different on the 2 servers, it is possible that the date / year is accidently wrong - certainly worth checking out while the bods at actinic look into it.

[Pneumatus]

I had thought the same, but....

http://www.glowsticksdirect.co.uk/date.php
https://www1.securesiteserver.co.uk/glostidirk/date.php

Both of these now show identical date/times and the same timezone.

[Pneumatus]

I don't know if anyone from Actinic had a chance to take a look but i've had to switch it back to Java encryption so I can hopefully take a few orders tonight...

If you need any more details etc let me know...

[cdicken]

This is from one of our head developers:

I think the problem is not the time zones, as one hour difference can not cause a cart expiry. This message is also shown when a checkout call is made and the session file is not found.

As the site works on split ssl, it is possible that the ssl path points to a
different path.

May I have the exported network settings and the web server configuration
files for normal and ssl connections?

So you can go to 'Export' in 'Advanced | Network Settings' to export the settings and attach them here - don't forget to blank out any passwords.

I guess the webserver config files are the Apache httpd.conf files (or equivalent). Feel free to send all the files to me at communityadmin[@]actinic.co.uk and I'll pass them on.

[Pneumatus]

Although it is 'split ssl',

http://www.glowsticksdirect.co.uk/ and https://www1.securesiteserver.co.uk/glostidirk/ point to exactly the same place as far as I'm aware. I'm not able to get hold of the httpd.conf but I have attached my network settings - as you can see, the ftp details for both sides of the split are identical.

[cdicken]

I have passed this on to the development team.

[cdicken]

Matt

Our developer says he would need SSH access (a type of secure FTP) to your secure server in order to discover the cause of the problem.

Can you have a word with your host and see if you can get those details?

[Pneumatus]

Unfortunatly there's no chance of getting SSH access to the server - the particular host that domain is on won't let us have SSH access under any circumstances

We have moved over to internetters SSL which is what most of our other sites use so I guess we will just have to write it off as a lost cause.

Thanks anyway