since the session ID is displayed in plain view in the browser's address bar and could be easily hijacked by a passerby

While I applaud your attention to security, I think you're passing the security boundary and into paranoia. If someone passing by can easily remember a sessionid then either your session ids are way too small or the person is wasting their time and should be in a casino somewhere counting cards.

But ... if you're still really worried, you could combine the true session id with something else, a nonce, that isn't seen by the passerby. Some people use the ip address of the incoming request but you really need to know your clients to do that (there could easily be lot's of clients coming from the same nat gateway). Or you could create a nonce on your own and insert it as a hidden field. The problem there ... every request would need to be a POST.

Personally, I've given up on the people who do not accept cookies. The only thing I try to do is minimize the number of cookies I create (I'm almost down to one!). It's a trade-off.

While I agree that concern with passers-by memorizing or writing down a session ID in the URL is excessive (especially since most sites' session IDs are tacked onto the end of a URL that's large enough that it isn't all displayed on the screen anyhow), putting it in the URL also means that it will be recorded in the server's access log as well as any intermediate proxy logs. Those logs may be readable by untrusted third parties, creating a possible threat. (I wouldn't go so far as to call it a likely threat, but it's nowhere near as remote a possibility as someone looking over your shoulder and getting it off the screen.)

In any case, like you, I've pretty well taken the position that cookies are a fact of life if you want to log in to a site, so just enable them (but disable third-party cookies if your browser has that option) and get on with it.

Amazon does both cookies and session ids in the path (and every URI on the page). As long as you are expiring these at the end of a "visit" and mixing in things like IP and user agent on the server side, this can work fine. Plus, with their model, they require a secure sign-in every time you perform account altering actions ("no" for putting something in the cart, "yes" for paying for something or changing an address).

If you do both, you can basically ignore whether or not the client supports cookies. Then again, cookies are so basic to web functionality today that I don't think the dual model is really justified compared to the extra overhead (URI rewriting) and complexity it adds.

Hi, Thanks all for the useful link and suggestions :-)

I think Mr. Schwartz's method is pretty much helpful(basically I think it takes the same approach as shown in Gavin's above post). So every first-time visit to my website has to take a test to check if the browser responses with a proper cookie information. Sounds a perfect solution and I don't need to issue any redundent information on the URL after then.

the only downside I can feel is that for the first time visitors, this approach means an extra 302 redirection when they first see my webpage, and if the visitor is a robot which usually doesnt accept cookies, this approach might double(not double exactly since redirect happens at early stage) the net-flow from those robots:--((( but it should not be a big problem by caching from both client and server side.... not sure if there is any other side-effects though?

very nice learning... thanks :- )

Regards,

lihao(XC)