The web, in general, is stateless, and http is a stateless protocol.
The upshot of this is that every time you send a request to a web
server it has no idea who you are without some identifying piece of
information.
So, once a session has been set on a server, that session has an ID.
The user has a cookie on their computer that contains the ID of that
session. Without that ID, the server has no idea what session to look
up, so if you call session.getAttribute("userId") without the client
sending a session ID, you wouldn't get back anything. Every request
the user makes to your server, they're sending across the cookie with
that session ID so that your server knows what session information to
look at. Keep in mind that there could be any number of users on an IP
address, so IPs can't be used for that sort of thing (not to mention
IPs can be spoofed, so if servers used IP addresses for that sort of
thing sessions could be hijacked extremely easily!)
As far as rebooting their PC: that entirely depends on both your
server session and cookie settings and the user's cookie settings. The
cookie can be temporary so that as soon as they close their browser it
disappears, it can be effectively permanent (set to expire 1000+ years
into the future, for example) or anything between. You can set your
sessions on the server to expire as quickly as you like as well. If
the client's cookie goes away, they won't have the session ID to use
to call up that session. Similarly, if the session expires on the
server and thus is deleted, the user would be logged out even if they
still have the cookie.
So that's why when you're sending RPC requests to your server, unless
those requests should be able to be made by the public in general, you
need some form of user identification/authentication on them.
Otherwise I can just produce my own RPC request to your server outside
of your app and perform any RPC request I want.
There's quite a bit of reading on this topic, but hopefully that's a
decent overview to give you a bit better understanding of what's going
on. Feel free to ask more questions and I'll try to help.
On Oct 22, 4:22 am, Josh <josh.e.ander...@gmail.com> wrote:
> I'm new to sessions and I could use a little help in understanding
> this.
> If you log in you send your username/hash password.
> The server validates this data.
> The server creates a new or accesses a current one already created for
> you.
> Fills the sever session with user data.
> Returns a session Id and places this Id in a database of valid
> sessions and maybe your ip address and say your userId.
>
> Q: why is a session Id needed does the server not know who is sending
> the RPC? could i not just call session.getAttribute("userId") on the
> server side?; regardless of a sent session id?
> Is the point of a session Id just so someone can't fake your ip
> address and send requests to the server as if they were you?
>
> Q:If you give a session Id out and it's saved on the clients side in
> say a cookie. Then if the user reboots their pc and opens up your
> site. This is where i'm confused.
> Your page should display a login not right? so...
> The client sends the server it's session Id, the server sees it's in
> the valid session database but is your session data still alive? on
> the server does the server still know your the same person because of
> your ip?
>
> I don't see where a session id is used at any point other than
> verification of who the client is. So is that the only point of a
> session Id to add security as to who is sending the RPC to the server?
> Will i have to check the session.getAttribute to see if it even has
> data even if i have already checked to ensure the session Id passed to
> me is valid? Is that the point of a sesson Id to rebuild a sesson
> Attribute if it expires on the sever before you clear it from your
> valid session table?
>
> HttpSession session = getThreadLocalRequest().getSession(true);
> session.getAttribute("userId");
>
> If anyone could clear this up or offer some other reading on this
> topic please do.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
