gdstark
Posts: 12
|
| Posted: 04/17/2007, 4:36 PM |
|
I would like to track unique users WITHOUT any sort of login process. Specifically I would like to take a first time visitor, assign them a unique visitor ID (sessionID?) that I store in a cookie with effectively no expiration date. Yes, I realize that all a user needs to do is delete or disable cookies, but I can live with that. So my question is this: is there already a unique session ID being assigned when a session starts that I can use? Or do I need to somehow create this?
thanks,
gary
|
 |
 |
Benjamin Krajmalnik
|
| Posted: 04/17/2007, 7:37 PM |
|
All codecharge pages automatically instantiate a session.
To access the session ID ou use the Session collection in ASP.
Session.SessionID holds the unique session id. However, I believe you are
overcomplicating the issue.
You do not need to set a cookie - it is already maintained for you.
No, the only problem is that the SessionID is not absolutely unique
|
|
|
 |
Chris__T
Posts: 339
|
| Posted: 04/18/2007, 11:16 AM |
|
I think you would use something like this:
CCGetSession()
Maybe?
|
 |
 |
Benjamin Krajmalnik
|
| Posted: 04/18/2007, 1:16 PM |
|
No,
CCGetSession is used to retrieve a session variable.
The session collection on the server retrieves the variable based on your
session ID.
To retrieve the session id you use the session's collection
Session.SessionID
|
|
|
 |
gdstark
Posts: 12
|
| Posted: 04/23/2007, 7:52 AM |
|
Quote Benjamin Krajmalnik:
No,
CCGetSession is used to retrieve a session variable.
The session collection on the server retrieves the variable based on your
session ID.
To retrieve the session id you use the session's collection
Session.SessionID
Hi Benjamin,
That seems to be it...thanks! Reparding your earlier comment about overcomplicating the issue, I'm not sure I understand. Yes, I realize that during the session it's already maintained, but I'm hoping to use it on return visits so I can treat this person as a "known" user. And to do that, I plan to store the first ever visit's sessionID in a cookie with a long expiration date. Yes, I fully realize that the user can defeat this system by simply deleting the cookies, but my application is not that critical so I can live with that. Does that make sense?
(btw, sorry for the late reply on this issue...for some reason I only today got the email alerts that you had posted.)
gary
|
 |
 |
Benjamin Krajmalnik
|
| Posted: 04/23/2007, 3:22 PM |
|
I am not sure what it is you are attempting to do - bypass the login?
If so, storing the an old sessionid is irrelevant, since the session no
longer exists on the server.
What are you going to validate against, and more important, how you will
know the identity?
Especially since a session id is not unique - it could be reused at some
poin in the future.
>
|
|
|
 |
gdstark
Posts: 12
|
| Posted: 04/24/2007, 7:40 AM |
|
Quote Benjamin Krajmalnik:
I am not sure what it is you are attempting to do - bypass the login?
If so, storing the an old sessionid is irrelevant, since the session no
longer exists on the server.
What are you going to validate against, and more important, how you will
know the identity?
Especially since a session id is not unique - it could be reused at some
poin in the future.
>
Benjamin,
I don't have a login...my users are completely anonymous. Check out the website...
http://www.ExpertVoter.org
If you click on a video link, you'll see that there's a feedback form below the movie window. When this form is submitted I want to pass the user's unique ID (his first ever sessionID) so that I can ignore repeated feedbacks to the same movie.
I definitely don't want a login process. Given that constraint, how would you handle this problem?
much thanks,
gary
|
 |
 |
Wkempees
|
| Posted: 04/24/2007, 7:59 AM |
|
If you do not want a login process, leaving you withou a UserID,
my approach would be to presetn the user with a minimal recordform.
the record form would be on your user table, and have insert allowed
yes, all others no.
You put this form in your process flow, it will be called without a URL
UserID, so automatically be in insert mode, your visitor enters his data
and pressed Insert (rename it to Next), the record will be added.
In PhP, we would then catch the last_insert_id() and set that in the
session.
Which would solve your approach.
Walter
|
|
|
 |
Benjamin Krajmalnik
|
| Posted: 04/24/2007, 4:11 PM |
|
If all you want to do is know he has visited before anonimously, you can
just place any a cookie with any value. You do not need a sessio id -
again, it is irrelevant. Also, this is pretty limited because many people
clear cookies daily.
|
|
|
 |
gdstark
Posts: 12
|
| Posted: 04/25/2007, 7:16 AM |
|
Quote Benjamin Krajmalnik:
If all you want to do is know he has visited before anonimously, you can
just place any a cookie with any value. You do not need a sessio id -
again, it is irrelevant. Also, this is pretty limited because many people
clear cookies daily.
True, it could be any value. The only reason I thought of using the Session ID was because it was unique, at least that's my assumption. I suppose I could just as easily create a new user record for new visitors (those without the cookie) and store the record ID into the cookie instead.
You mentioned that many people clear their cookies daily. I don't know anyone who does this. I'm sure you're right that some do, but I would think it's a very small minority. What would be the point? Anyway, since my use is not critical at all, it might still be fine for me.
gary
|
 |
 |
|