Loaded Commerce Community

Problem with session id's being part of inbound links, customers are automatically logged in as the most recent person to have created an account or placed an order on that same session id, with FULL access to their entire stored details!

Google Adwords set up 25 ads for my client, 17 of them had the session id as part of the URL.

For 6 weeks my client ended up with orders going to the wrong people or customers phoning up to say they could see someone elses details when trying to order online.

My client made it to 29,000 orders without a problem, then we had 6 weeks of chaos whilst trying to find to cause of the problem.

We changed all the Adword ads and instantly the issue stopped.

We're now trying to set up add this / share this buttons, but can already see the session id is part of the shared URL.

Is there a way to detect if someone's visiting from outside of the site and force a new session on them to prevent this?

Or am I simply handling sessions wrongly to cause this issue in the first place?

This instance is 6.2 patch 14 but also tested and seen on 6.4.1a

Google indexing urls with session ids is bad enough, but someone actually added these to an adwords campaign?! Wow. What to do:

#1 upgrade - more reasons to move on from 6.2!
#2 check how sessions are being handled in the admin >> configuration settings plus by the server itself
#3 if you have htaccess-ability in the root of the store, these lines might help:



A session appended url will appear store-side ONCE on login. That's all I see.
Admin sessions are different and appear all the time.

Simon

Hi Simon,

Thanks for taking the time to reply.

#1 I know all the arguments for upgrading, but the client is in the middle of moving premises and is resisting any changes until that's over with. I pester him on a daily basis, especially as pretty much every issue he has is met with 'upgrade, upgrade, upgrade'! ;o)

#2 Sessions are handled as:

Admin/Configuration/Sessions:
Session Directory /tmp
Force Cookie Use False
Check SSL Session ID False
Check User Agent False
Check IP Address False
Prevent Spider Sessions True
Recreate Session False

Stores configure.php:
define('USE_PCONNECT', 'true'); // use persistent connections?
define('STORE_SESSIONS', ''); // leave empty '' for default handler or set to 'mysql'

Admins configure.php:
define('USE_PCONNECT', 'true'); // use persisstent connections?
define('STORE_SESSIONS', ''); // leave empty '' for default handler or set to 'mysql'

Any pointers on these gratefully received, although aside from this issue, everything else works fine.

#3 I added the code to the htaccess file but still see the oscsid throughout the site, should it be stripping it?

ShareThis did tell me I could:


But this is all pretty foreign to me and it would be nice to know how to kill the issue locally as surely anyone emailing a link to the page they're viewing direct from their browser or as I do all the time from my phone will also be sending their session ID and therefore access to all their info?

Slight amend:

Added

to the start of the rewrite argument in htaccess, now we have no session ID showing but all links end up at the homepage - I think maybe as we have a 404 redirect to same?

Wow, who setup this store?

I wouldn't use:

Storing sessions in a folder isn't good, esp in a 6.2 store.

Instead:


Simon

Hi Simon,

I changed those values, thanks for your input.

I also spotted somewhere else on the forums - http://creloaded.org/forum/topic.html?f ... l&start=30 - that I should set 'Force cookie use' to true in order to remove the oscsid from the address bar.

I did this and the address bar was perfect ;o) Short lived though as I soon realised it is now impossible to place anything in your basket - grrrr

When clicking add to basket, the store tells me 'your basket is empty'. I changed it back to false and hey presto, we can now put things into the baskets again.

Is there a way I can have the oscsid removed from the address bar but still have the basket actually work?

Forcing cookie usage isn't going to help. There are server issues with the cart by the sounds of it, so no amount of tweaking the cart settings seems to work. Bit tough to do much here - had a look at Admin >> Tools >> Server Info for any red crosses?

Simon

Hi Simon,

Again thanks for your time.

I took your advice and checked the server info, there is one red cross alongside 'PHP Mcrypt'. Is this something that would allow us to strip the session id from the url? Or just something that could do with sorting.

To recap, we have no operational issues with the site aside from the fact that in order to use the various social share buttons, etc. we need to be able to remove the oscsid from the url, as we did have some issues with Adwords using the url inclusive of a session id (changed the adwords url's now).

Yeah, you've gone from "customers can log in to other customers accounts" to now "it's just the social button urls that we don't want session ids on" ... so bit of a change from the original eh? Find someone who can rewrite the htaccess mod I posted specifically for your social links then - osIds shouldn't be an issue UNLESS there's some misconfiguration / tweaking been done. Bottom line - upgrade.

Simon

Hi Simon,

I know upgrade to be the best root, just waiting on the client arriving at that same conclusion ;o)

The issue is / was, all one in the same - with the oscsid as part of the Google Adwords link (as set up by Google for the client), site visitors were automatically logged in as the most recent user of that same session ID - obviously not acceptable but solved once discovered by removing the session id from the Adwords campaign.

So now we want to run social buttons but can see exactly the same thing will happen again as the oscsid is shared on each social share made. Hence the need now to remove the oscsid from the address bar if possible.

Sorry if on my 'journey' I hadn't logged the various stages, I guess it's one of those situations where you think / hope everyone else knows what you're thinking ;o)

Thanks for all your input

Steve

Are you sure your cookie path is set right in the configs?

Hi 'cheapo',

I was sure - until I found a mistake!

[walks away sheepishly]

Things are making a lot more sense now!

Thanks all ;o)