Should I use sessionID to uniquely identify users?
NO, that’s why UserId/UserName or LoginID and password combinations are for.
SessionID is a “random” string and can be repeated (e.g. when IIS is restarted or the server is rebooted, the sequencing scheme that generates SessionID values is reset). So if you store information for a user based on the SessionID value, be very aware that a new person next week might happen to get the same SessionID value–this will either violate a primary key constraint, or mix two or more people’s data.
However in ASP.NET, the SessionID is 120 bits in length, so like a GUID, is virtually guaranteed to never repeat.
But in classic ASP, this built-in mechanism is not a good strategy for identifying users over the long term. A better methodology would be to generate a key value in a database that is guaranteed to be unique (e.g. IDENTITY or AUTOINCREMENT) and store that in a cookie on the client. Then you can identify them not only for the life of their current session, but during future visits as well (of course, only until the next time they delete their cookies).
As usual, it depends, on the technology you inherit, how the old modules were built and so on.
Storing ASP.NET SessionId and at the same time storing a SessionGUID generated from the SessionId in ASP.NET doesn’t make much sense.
L.