Many of you may aware that AOL using floating IP address to manage their internet connection. When I develop my shopping cart, I used IP address as one of the variables to identify user (other variables are datetime and url) and its shopping cart content. It was alright until someone using AOL to browser the site. I'm forced to use only two parts of the 4-part IP address to avoid any error due to floating IP. The code is so far running ok, however, I'm not convience it will stay ok forever as floating IP can change all four parts of the IP address. Can anyone suggest a better way?

Note: I'm not using session nor cookies as some people disabled these beautiful functions.

Without cookies or sessions you've run out of options. They are really the only other options you have.

I guess you could make the users reauthenticate on each page.

Try your best to get those functions reenabled, for if you make a "shopping" site inconvienent in any way, users will tend to find another one that's not so inconvienent. (I'm echoing usability expert Jakob Nielsen's thoughts -- http://www.useit.com/)

I guess you could make the users reauthenticate on each page.

I do not use users authentication as my website (should be 'service' to be more precise) provide shopping cart facility to hundreds of websites, which do not require user to login etc.

Hello,

If you consider that VBulletin software must also be aware of this, they have come up with a solution to that very problem. It is a combination of cookies, license key and basic user details stored into a cookie for page to page retrieval.

If you do not use cookies you may have run out of alternative options.. I think.

Many of you may aware that AOL using floating IP address to manage their internet connection. When I develop my shopping cart, I used IP address as one of the variables to identify user (other variables are datetime and url) and its shopping cart content. It was alright until someone using AOL to browser the site. I'm forced to use only two parts of the 4-part IP address to avoid any error due to floating IP. The code is so far running ok, however, I'm not convience it will stay ok forever as floating IP can change all four parts of the IP address. Can anyone suggest a better way?

Note: I'm not using session nor cookies as some people disabled these beautiful functions.

Though not as secure as a cookie based session (Yes sessions are actually just cookies) PHP has the option of using a url based session.
http://us3.php.net/session
If this is disabled on your PHP you can enable it in php.ini by setting session.use_only_cookies to 0.

If you dont have access to php.ini you can set this in either .htaccess or within your php script.
To do this with .htaccess use add this line:
php_value session.use_only_cookies 0
In your php script use:

ini_set("session.use_only_cookies", "0");

Url based sessions should always work since they dont require cookies but instead append the sessionid to the url.

I disabled session.use_only_cookies as I come across a few articles that saying the PHPSESSID is not search engine friendly?? I think this spark the idea of having my own string attached to the URL and recapture it on every page using $_GET function :cheesy:

Yes, that may be true about PHPSESSID, however, you can change the value of PHPSESSID to something else by changing session.name in php.ini or use .htaccess or ini_set().

I dont think changing the name of PHPSESSID would do any good though as it is the long hash value of the session id that is meaningless to search engines.

The googlebot is quite a bit smarter now that it was a year ago. So the articles on the web are always outdated as far as SEO. You'll have to test that yourself to make sure.

The googlebot should not reach your pages that have sessions implemented anyway. Googlebot wont be buying anything from your e-commerce store. The session enhanced part of your site should be for buyers only if not just humans. You really only need the session after a user has purchased an item. If googlebot purchases an item and checks out, I think that would be a first. ;)

As someone whose primary business is training Web development teams in SEO methods, my advice is to NEVER allow session IDs in URLs. Take my word for it, Google is NOT smart enough to recognize a session ID. I also run a Web directory and I see dozens of 50-page sites each week with thousands of URLs in Google's index--all of which are banished to Supplemental Results. Anything that alters a URL can create duplicate page URLs and duplicate content penalties with search engines. Session IDs create duplicate URLs that do create problems.

Google's Webmaster Guidelines specifically cover this issue.

"Allow search bots to crawl your sites without session IDs or arguments that track their path through the site. These techniques are useful for tracking individual user behavior, but the access pattern of bots is entirely different. Using these techniques may result in incomplete indexing of your site, as bots may not be able to eliminate URLs that look different but actually point to the same page."

http://www.google.com/support/webmasters/bin/answer.py?answer=35769

There are two workarounds for this if you must use session IDs in URLs:

1. Use PHP code to detect search engine spiders and do not initiate a session when a spider requests a page. You can easily detect a spider using $_SERVER.

2. Do not initiate a session until an item is placed in the shopping cart (as digital-ether mentioned). Because spiders cannot place items in a properly designed shopping cart (never use hyperlinks to place items in a cart), the session ID never displays in the URLs when spiders are present.

Hope this helps. :mrgreen:

BTW, almost every Web developer who has ever created an e-commerce site has had to deal with AOL's abundance of deficiencies. That's what happens when you do not follow Internet standards.

That's a pretty interesting story. It's funny that someone would think that a cookie could be used to block someone's access. The story sounds a bit suspicious, but it is possible. Actually, no spider can accept cookies or sessions, nor can they execute code. All they can do is request the script, read it and parse it. . . and they follow the hyperlinks that they find. If someone actually did build a CMS system that was that weak on security, anyone who turned off cookies and JavaScript would bust right through it.

If anyone else is interested, both MSN and Yahoo have guidelines pages similar to Google's.

Webmaster Guidelines

.

This article has been dead for over six months. Start a new discussion instead.