Forum Moderators: buckworks
After collecting data for a couple of days I found that an average of 1.5 % of the IPs logged caused problems of some kind, most of them due to this issue, I assume. Some of these supposedly were spiders, who wouldn't try to order anyways.
As we all know, php session management bears very elegant and easy to program means of performing the necessary communication between browser and server-side-scripting, which shop-functionalities require. And it is not easy to develop a workaround: Most tutorials on this recon to add session IDs as a get-variable (which is just a question of setting php.ini), but other sources stress the serious security-risks of such a solution.
So my question to those of you who thought about -or perhaps even mastered- this:
1) Is the percentage-figure given above in accordance with your data?
2) Are these few people (=difficult customers, presumably, eh?;) worth the effort?
Most carts or sites require cookies enabled ebay, paypal webmasterworld and so on the list so I would say not worth the effort.
But still, I program in traps for no cookies. If I can't set a cookie or run Javascript, the user is informed they cannot add to cart and will need to check out with a single item. A link is provided to a page that explains what they do, how to enable them, and so on.
Yepp, I thought about that, but then I realized I wouldn't know how to decide an SE-spider form such a user, and I assume many of those spiders will not allow cookies.
I don't really know about google, but any such spider would be quite annoyed to read all this technical info on ALL of your pages? And how do you know google doesn't check your page "incognito" sometimes in order to test, whether you are cloaking?
I also have a technical question, but maybe this is better to be asked in another forum: I have a database where I store initial info on the IP, referer and session ID and so on, each first time a new visitor arrives. In case a visitor does not allow cookies, the $_SESSION-array under php will not be set by the second page he views, but there is this entry in my database. If I now - before/instead of setting a new session id - request this database-entry, checking IP and probably a time-stamp (less than half an hour ago or so): Can I then simply SET the $_SESSION['PHPSESSID']-Variable and all the other array-vaiables of this session will be restored by the php-session management? Would this be such a workaround without transmitting the session-id via GET? What security issues come to your mind?
any such spider would be quite annoyed to read all this technical info on ALL of your pages?
Well, I just use these traps where they are required for user interaction - when someone submits an item to add to cart, for example. So it's not that prevalent and doesn't affect SE's.
As for your other question, if you're saying what I think you're saying, that is the "old school" way to manage it, you carry around a session ID number in hidden fields and query strings, and compare it with a sever-side stored value to connect it with their data. This is how I manage carts if there's no cookie to work with. I can't think of an immediate security issue unless that value can be injected to peek into other data:
sessionid=select+1=1+from+session_table+left+join+on+cc_info
[small]probably an invalid inject, but you get the idea.;/small]
I had this database anyways, where I started to log initial entries like IP, referer, time, date and so on (one entry per visitor). So before setting a new session ID
= either a new visitor or one with disabled cookies has avrrived
= if (!isset($_SESSION['PHPSESSID'])){...
, I now perform a check, whether there was a previous entry under this IP within the last half hour. If so, I take that session ID, if not, a new session is started.
However some minor problems occured, which deserved a solution:
1) E.G. google-bot seems to pass by every 20 seconds or so, so he'd never receive a new session ID, which might result in an overflow on the pages-visited entry next century;) so I now have two timestamps in that database: Time of first and last visit. If the last visit is less than half an hour ago, I suspect this is the same visitor, but if the first visit is more than three hours ago, a new session is generated.
2) I realized that I hardly use the session array for purposes other than re-identifying the visitor. Most of my actions are database-driven meanwhile, I think what has remained as session variables could well be programmed with normal variables or arrays. Seems I don't need the session array at all any more.
