eags,
In my apps, I generally keep a reference to the User object within the
app. Since, my current app works with browser history and can be
called with various urls, I check for the existence of a User object
after I parse the url, but before I load and show the content
referenced by the url. If there is no User object, I know the user is
just coming in and I can force a login.
HTH,
Chad
On Jun 9, 1:09 pm, eags <eagsala...@gmail.com> wrote:
> Someone I talked to in person (who otherwise didn't know about GWT
> RPC) suggested I also store the role as in
> {username,sessionID,timeout,role} so that I don't have to fetch and
> otherwise mess with the user object every request. Does that seem
> sane? I suppose I could also store a reference to the User object
> since that is likely to get referenced pretty regularly. Any issues
> with that scheme? (again assuming that storing the sessionID manually
> is what I'm supposed to do at all).
>
> On Jun 8, 11:27 pm, eags <eagsala...@gmail.com> wrote:
>
>
>
> > 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
-~----------~----~----~----~------~----~------~--~---
