You could also encrypt the information in the cookie. Make sure you use some salt.
On Wed, Dec 3, 2008 at 10:50 AM, Jeremy Thomerson <[EMAIL PROTECTED] > wrote: > Yes, you need a token to look up the user by. But username sent in the > cookie isn't secure enough (i could send cookie w/ your un and be you), and > you shouldn't put password in a cookie. So, typically you create a UUID > when they sign in and use that as the token. Or a hash of something from > user. > > > Jeremy Thomerson > http://www.wickettraining.com > -- sent from a wireless device > > > -----Original Message----- > From: Casper Bang <[EMAIL PROTECTED]> > Sent: Wednesday, December 03, 2008 5:55 AM > To: users@wicket.apache.org > Subject: Re: Why can't I initialize PasswordTextField? > > Yeah I thought of the security issue, it seems though quite a few PHP > sites works like that (not to mention, build-in browser functionality > which does the same kind of unsafe client side caching). > > In the idiom outlined in your source code, how can the server then > re-authorize without username and password. I assume the user table then > have to include a session field that is transferred and stored upon > initial login, and which is used to match up against on successive logins? > > /Casper > > > Jeremy Thomerson wrote: > > May I answer your question with a question? > > > > Why would you want your password field to have the value pre-filled on > the > > page? Then the password is in plain text available to the user (and > > assuming you're not on https, anyone in between). I've never seen an > > instance where this was a good idea. > > > > If you're trying to do an auto-login, you shouldn't show the login page > at > > all. Pseudo code would be: > > > > if (getYourSession().isSignedIn() == false) { > > String token = getCookie(someCookieID); > > if (token not null and not empty) { > > User user = lookupUser(token); > > if (user != null) { > > getYourSession().signIn(user); > > } else { > > // only here would you show login page, without anything pre-filled > > because > > // they're not already signed in and they don't have a cookie to > sign > > them in > > setResponsePage(YourLoginPage.class); > > } > > } > > } > > > > On Tue, Dec 2, 2008 at 9:26 PM, Casper Bang <[EMAIL PROTECTED]> wrote: > > > > > >> I'm trying to implement credentials memory functionality for a login > form > >> using cookies. I know there's an official example ( > >> > http://wicketstuff.org/wicket13/signin2/?x=7*:org.apache.wicket.examples.signin2.SignIn2 > ) > >> however it simply delegates to some panel which is not available as > source > >> on the page. So anyway, it should be simple, and all works great except > that > >> I can not get the password field to get filled out upon page load. In my > >> constructor of my panel I do the following: > >> > >> Cookie credentials = > >> ((WebRequest)getRequestCycle().getRequest()).getCookie("credentials"); > >> remember = credentials != null; > >> if(remember){ > >> String[] credentialParts = credentials.getValue().split(":"); > >> username = credentialParts[0]; > >> password = credentialParts[1]; > >> } > >> > >> The fields username and password of the panel are bound to the form > using a > >> CompoundPropertyModel. When I sniff request and response headers, I can > see > >> that indeed the cookie info is sent around fine. I guess it has to do > with > >> security somehow, but shouldn't this be possible even if I am using a > >> PasswordTextField? > >> > >> Thanks in advance, > >> Casper > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
