So I read the LoginSecurityFAQ (http://code.google.com/p/google-web-
toolkit-incubator/wiki/LoginSecurityFAQ) and I plan on implementing
logins exactly as in the FAQ. At a high level I believe I get it but
need help on the specifics so please be as detailed and specific as
possible in your responses. A link to an actual implementation of the
LoginSecurityFAQ's method would be ideal.
So here is my notion of what I need to do with some questions about
details:
1. I'm planning on using the google app engine's JDO implementation to
store all data. For each User object I intend to store the userID and
the jBCrypt hash of the password along with whatever other user data
in the same object. When a new user registers, I'll create a new User
object and store it.
2. When a user tries to log in the server uses the username to fetch
the User object and the associated hash to check if the supplied
password is validated by the hash.
Here is where I get confused and am not sure but here is my best
notion of what I should do:
I return a sessionID to the client. I have seen people mention in
other posts that a sessionID can be fetched by doing:
getThreadLocalRequest().getSession(); on the server. (Also do I want
to return the HttpSession or the use getSession.getID()???) Or can I
use any random number?? (sounds wrong). However I generate it, Is
this session ID something I need to store using JDO along with the
username and a timeout value so that I can subsequently validate that
the session exists and is still active? Or is the session and
sessionID something that just exists on the server and I just need to
get a reference to?
Either way I'm still fuzzy on details. If I do store
{username,sessionID,timeout} in a DB, do I then need to periodically
clear stuff out of there?? If they explicitly log out I can see
removing the object but if they just close their browser it would just
grow and grow right? I guess if don't duplicate usernames when adding
new sessionID at worst this table would contain all my users all the
time and have a bunch of timed out sessions.
Also, How do I invalidate a session ID right when they close their
browser? I guess I could first check for the existing session ID and
if the timeout indicates it shouldn't persist over browser restarts or
page closing then I can compare to getThreadLocalRequest().getSession
() and see if they are the same (will subsequent calls result in the
same sessionID iff the browser window hasn't been closed)?? Also how
do I know there are no duplicate sessionIDs handed out over time where
more than one might be active at once (if I wanted to allow users to
stay logged in perpetually?). I'm trying to answer some of my own
questions but I'm very fuzzy here.
If I don't store {username,sessionID,timeout} in a DB (and always just
use getSession().getID() to compare what the client sends me), how
then can sessions remain active for weeks even across closed browsers,
etc (assuming I do the thing where I store the sessionID in a cookie
and retrieve and try it before trying a new login).
Also, I never saw any mention of sending the username along with the
sessionID. Is that right?
Anyway, moving on to more confusion:
The FAQ mentions specifically that the sessionID should be included in
the *payload* of every subsequent RPC request. Does "payload" just
mean an additional argument in the interface methods in the service
like (from the GWT StockWatcher tutorial):
StockPrice[] getPrices(String[] symbols,String sessionID) throws
DelistedException;
Or are we talking about some other way to pass this to the server?
OK. Now on to a couple related GWT RPC questions.
So I have a few things the server will be handling for me, for
example:
String sessionID login(username,password);
String sessionID register(username,password);
bool isLoggedIn(String sessionID);
void logout(String sessionID); // requires sessionID or no? I guess
not really needed
and
doSomeAdminThing(Object data, String sessionID);
doSomeUserThing(Object data, String sessionID);
doSomeThing(Object data);
Do people typically group related functions (like
login,register,logout) into a single RemoteService interface? Or each
function its own service? Or all functions for a given app grouped in
one big service (maybe required for session somehow?)
Last question is regarding authentication. Using the three doSome*()
methods I describe above, the idea here is that there are different
things available to different users and I'm thinking I entirely
regulate that on the server side and would just have a line of code
that checks something like if( User.getUserType() != User.type.ADMIN)
throw something at the beginning of each service method. Does that
seem right?
That's it! Feel free to mention anything I didn't ask about but am
obviously missing or should know. As you can see I'm definitely just
learning here and need lots of help.
Thanks very much in advance for all help.
--~--~---------~--~----~------------~-------~--~----~
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-Toolkit@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
-~----------~----~----~----~------~----~------~--~---
