It's done by an "authentication cookie". The usual method is, the
server creates a "ticket" when you login in and stores it in a cookie
for all your same-domain requests from the same machine.
A <someone@somewhere.com> said:
>if a client Y manages to find the session id by which ever way, it should
>not be so difficult to pretend to be clientX and attach to clientX's
>httpsession on the server... Probably one way to kind of protect against
>this would be to associate sessionid and ip and deny access to anyother ip
>trying to access the session... but how do popular servelet containers,
>j2ee servers handle this ?
... but binding session id to the connection source IP is problematic,
because:
- client address can change between two successive requests (DHCP
re-negotiation with address renewal)
- client can use a clustered proxy, which shows as a bunch of
source addresses
... and thus, it is deemed that just making it hard enough to guess the
session id is enough. SSL (with trusted server certificate) is used when
server non-repudiation and content trustworthiness/secrecy are desired.
SSL wil also protect the content of session ids over the network (but
of course not on the client).
>This mystifies me- perhaps its something simple but I cant figure it out.
>On yahoo for instance if I login to my mail.yahoo.com but then type in
[quoted text clipped - 4 lines]
>How does the server know to find my name in my authenticated session and
>serve a personalized page ?
Hmm.. SSL connection can well have a session id (mostly to avoid costly
SSL session re-negotiation for each request), which is invisible at the
HTTP level (but still usable on the server side) - if mail.yahoo.com is
SSL-protected, that is; I didn't check.

Signature
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)