Re: Very basic LoginSecurityFAQ and GWT-RPC questions
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 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 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
Re: Very basic LoginSecurityFAQ and GWT-RPC questions
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 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 servi
