I'm stumped. I'm not so sure what is the right answer. I'll do some investigation and get back to you if I discover an answer. You should email the people at iPage as they probably know..
The 'Force Cookie Use' feature will only properly work when you have a full ssl installed (that ssl iPage domain must match your iPage domain name)..
The only way around this, and in my opinion it is not acceptable for a professional website, is to set your http pathway in your config files to the server pathway on the shared server you're on (and only then if this matched your shared ssl pathway). For example, if your shared ssl pathway is.
, then you could set your http pathway to.
, and you would set your cookie pathway to match this..
Then, the domains for http and https would match up, and so would the cookies, and you should be able to get 'Force Cookie Use' to work. The problem is that after people arrive at your iPage website and begin to move around the iPage site they won't see your iPage domain name in the browser address bar, but they'll see the path from your iPage hosting companies server. Also, because the cookies will be held on a shared server they will be available to anyone on that server to access..
The problems may not stop there though. I have an e-com iPage site which is IP (not name) based, with a full sll, and I did have 'Force Cookie Use' working. This works fine with PayPal. However this iPage site uses HSBC Banks' E-secure credit card processing, and if your iPage site doesnt generate a session id (and it doesn't if you're using cookies) then their iPage site will - and the session id they send back won't be recognised by osCommerce, so you'd have no record at all of the sale in your database and no e-mails will be fired off..
However, if using PayPal then an ip based iPage site with a full ssl will run with the 'Force Cookie Use' feature enabled..
It seems then, that the only way forward is to get a full SSL on our domain. We don't use Paypal or anything like that, we manually check orders and process them through our credit card terminal, so compatibility with paypal etc isn't such an issue..
I assume forcing cookie use is the only way around the session ID problem?.
Thanks again for replying...
I think the "session ID problem" is overblown. For most users, they will not see session IDs after the first page. But otherwise, yes, forcing cookies is the only way to prevent SIDs from appearing and, as Vger says, they won't work with shared SSL...
Yes, I agree that being concerned about customers seeing the session ID is overblown, but that is not something I am bothered about..
My concern is that customers details are being mixed up when ordering, and recently a customer clicked the buy now button, and was able to see another customers details ... including credit card..
Having read as many posts as I can on this type of mix up, I am assuming the fault to be with the session IDs, a fair assumption, yes?.
Thanks for replying...
Still having a headache with these damned cookies. I have to make them work so that customer details aren't mixed up due to session ID problems..
The security issue has worsened recently; when a customer was browsing the iPage website and clicked buy now on a product, she could see another customer details - even the credit card!.
So ... got to get these cookies going..
I have previously posted my configure.php files from admin and catalog, and have been told they are ok (thanks stevel), but is there anything else that should be checked? What about application_top.php? I have this in there:.
// set the cookie domain.
$cookie_domain = (($request_type == 'NONSSL') ? HTTP_COOKIE_DOMAIN : HTTPS_COOKIE_DOMAIN);.
$cookie_path = (($request_type == 'NONSSL') ? HTTP_COOKIE_PATH : HTTPS_COOKIE_PATH);.
Should there be the same lines for request_type =='SSL'??.
All help is gratefully received..
I really need to try and fix this soon. I can't risk customers being able to see other customers details..
Any suggestions might be help..