Servlet Session Tracking

[Zhao]

I got a session question:

As my understanding, servlet basically uses cookies / URL rewrite to
pass session info around.

What if
- the user turns the browser cookies off,
- after surf in web site with a session, say S, for a while,he reach
page P
- he bookmark P
- he types an external URL in the "location" field of the browser,
- and then come back to page P using his bookmark (access P without
rewritten
URL)

Can servlet still track that the user is still within S (logically the
user
haven't done his "session" yet - just check some external reference
before go further)?

Or we have to (or can only) consider he exit S when he visit an
external link?

thanks

 

[VisionSet]

I got a session question:

As my understanding, servlet basically uses cookies / URL rewrite to
pass session info around.

What if
- the user turns the browser cookies off,
- after surf in web site with a session, say S, for a while,he reach
page P
- he bookmark P
- he types an external URL in the "location" field of the browser,
- and then come back to page P using his bookmark (access P without
rewritten
URL)

Can servlet still track that the user is still within S (logically the
user
haven't done his "session" yet - just check some external reference
before go further)?

Or we have to (or can only) consider he exit S when he visit an
external link?

If he has cookies off, then the url (P) *will* have the sessionid included,
and as long as he returns to the page within the timeout period specified by
the developer, typically 5-30 minutes, then the session will be joined. If
longer than the timeout, then yes the session will be void and typically a
new one started.

 

[Zhao]

If he has cookies off, then the url (P) *will* have the sessionid included,
and as long as he returns to the page within the timeout period specified by
the developer, typically 5-30 minutes, then the session will be joined. If
longer than the timeout, then yes the session will be void and typically a
new one started.

I guess that you didn't pay attention to

"then come back to page P using his bookmark (access P without
rewritten URL)"

How can the url in bookmark includes sessionid?

Or let's make it even simpler: instead of

"then come back to page P using his bookmark (access P without
rewritten URL)"

the user type in the url of P from the "location" field of the browser and
assuming he does this before the session is timeout.

thanks

 

[VisionSet]

I guess that you didn't pay attention to

"then come back to page P using his bookmark (access P without
rewritten URL)"

I did, hence the:

then the url (P) *will* have the sessionid

emphasising the fact that if you bookmark a url which has url rewriting then
the session ID will be bookmarked, pretty straightforward that one!!

So basically I'm saying that this:

"then come back to page P using his bookmark (access P without
rewritten URL)"

Does not make sense, since that is not the case!

How can the url in bookmark includes sessionid?

Because it is part of the url.

Or let's make it even simpler: instead of

Or lets rephrase that, since you didn't know that the *whole* url is
bookmarked, and/or the fact that the sessionID is part of that url then if
the url without the sessionID is pointed to and with cookies off, then your
server will not be able to detect the correct session, and will either start
a new one or whatever your code decides.

Pretty immaterial really, since bookmarking is typically over days and a
session is typically over minutes.

 

[Sudsy]

I guess that you didn't pay attention to

"then come back to page P using his bookmark (access P without
rewritten URL)"

How can the url in bookmark includes sessionid?

Or let's make it even simpler: instead of

"then come back to page P using his bookmark (access P without
rewritten URL)"

the user type in the url of P from the "location" field of the browser and
assuming he does this before the session is timeout.

thanks

But if he bookmark it, not entire url stored in browser?
Not take him back to same page with rewritten url?
Otherwise cookie send automatically and invalid session
results, no?

 

[Zhao]

I did, hence the:


emphasising the fact that if you bookmark a url which has url rewriting then
the session ID will be bookmarked, pretty straightforward that one!!

So basically I'm saying that this:


Does not make sense, since that is not the case!



Because it is part of the url.


Or lets rephrase that, since you didn't know that the *whole* url is
bookmarked, and/or the fact that the sessionID is part of that url then if
the url without the sessionID is pointed to and with cookies off, then your
server will not be able to detect the correct session, and will either start
a new one or whatever your code decides.

Pretty immaterial really, since bookmarking is typically over days and a
session is typically over minutes.

VisionSet, thank you for your detail explaination.

That was what I wanted to make clear: without cookies and rewrite sid,
servlet (also session EJBs?) can not keep track the session.

Is there any way to get around?

How people deal with

"user who disable browser cookies jumps out of a sesioned page to an external
site and then come back by typing a popular url at the location field of
a browser"

if they still want the original session to continue?

thanks

 

[VisionSet]

But if he bookmark it, not entire url stored in browser?

Yes, entire url bookmarked, try it in either IE or Netscape...

Not take him back to same page with rewritten url?

Yes same page.

Otherwise cookie send automatically and invalid session
results, no?

We are talking about the case with cookies turned off, if cookies are turned
on, URL rewriting is automaticaly turned off, typically after the second url
is sent to that server.

 

[VisionSet]

That was what I wanted to make clear: without cookies and rewrite sid,
servlet (also session EJBs?) can not keep track the session.

Is there any way to get around?

How people deal with

"user who disable browser cookies jumps out of a sesioned page to an external
site and then come back by typing a popular url at the location field of
a browser"

if they still want the original session to continue?

I suppose you could also track IP address, there are no guarantees of course
but it could be useful in many situations.
Of course explicit logins also get round this, albeit with more user
involvment.

 

[Sudsy]

Zhao wrote:

How people deal with

"user who disable browser cookies jumps out of a sesioned page to an external
site and then come back by typing a popular url at the location field of
a browser"

if they still want the original session to continue?

You make it clear that your site uses cookies. If users want to
turn off cookies then they'll have problems using your site.
What could be simpler?
Playing all kinds of "what if" games is an exercise in futility.
You can't solve these PBKAC scenarios.

 

[Michael Borgwardt]

You make it clear that your site uses cookies. If users want to
turn off cookies then they'll have problems using your site.
What could be simpler?

Not forcing the users to use cookies and instead accepting that
a "session" simply *cannot* be continued after leaving the site?

I really don't see the problem.

 

[VisionSet]

How people deal with

"user who disable browser cookies jumps out of a sesioned page to an external
site and then come back by typing a popular url at the location field of
a browser"

if they still want the original session to continue?

If you want to have a look at a usecase diagram that I came up with to
analyse simple user authentication scenarios then have a look at this:

http://www.hotpud.com/beta/images/authenticate&login.gif

Note it concentrates on minimising user interaction, and does not deal with
secure logins for sensitive resources.

Happy to discuss any aspects.

 

[Zhao]

I suppose you could also track IP address, there are no guarantees of course

but it could be useful in many situations.

IP won't work since many users have dynamic IP.

Of course explicit logins also get round this, albeit with more user
involvment.

Authentication doesn't carry any timing/session info - it still can not
solve the problem of "users go out and back" problem.

....