Thanks guys. I looked at using the browser password manager btw, but I'm pretty sure it wouldn't automatically log the user in, just save the username and password, auto-populating those fields next time they visit your site. You still need to have some javascript to do the auto- login.
I was thinking though that instead of storing the session_id in a cookie, why not: 1) Create a hidden login form in index.html. 2) First time user logs in, the browser will ask them if they want it to store their username/password 3) If they had hit yes, then the browser should always auto-populate the two hidden fields for you. 4) Next time they visit the site, your javascript can just extract the username and password from the hidden fields, and just auto-log- them-in. 5) If the fields are not prepopulated, do nothing. What I like about the above is that you don't have to use any cookies, and you have the same server interface for logging in. Using the cookie auto-login method, I have two cases: 1) User logs in manually (supplies username/password) 2) User logs in automatically (supplies username/sessionid) it would be nicer to only have a single interface, but the cookie way ain't too bad. Thanks On Jun 18, 12:38 pm, Ian Bambury <[email protected]> wrote: > Everything is insecure to some degree, but provided you send the token for > ajax requests as a POST parameter and check that, then CSRF isn't really a > problem since the attempt to use your script from the remote page won't have > the correct token. > As for password managers, they don't, generally, keep you logged in, just > remember your password. > > Ian > > http://examples.roughian.com > > 2009/6/18 mars1412 <[email protected]> > > > > > > > Isn't that insecure regarding CSFR? > >http://www.openajax.org/whitepapers/Ajax%20and%20Mashup%20Security.ph... > > I must admit that I am a noob regarding security of Web-Apps, so > > please anyone correct me, if I misunderstood. > > > Another question is: why don't you try to use the passwordmanager of > > the browsers? > > this would even work, if cookies are disabled > > > On Jun 18, 11:30 am, Thomas Broyer <[email protected]> wrote: > > > On 18 juin, 06:13, markww <[email protected]> wrote: > > > > > Hi, > > > > > I have to implement an "auto login" feature for my web app. It seems > > > > the best way to do this is to use cookies. My server will have two > > > > tables to support this: > > > > > // users > > > > userid | hashed_password > > > > > // sessions > > > > session_id | userid | session > > > > > When a user visits my website, they can choose "login automatically". > > > > The first time they authenticate, they'll be entering in their > > > > username and password manually. When my server gets the authentication > > > > request, it sees if they want to use auto-login. If so, I generate a > > > > random hash for them and enter it into the sessions table: > > > > > // users > > > > userid | hashed_password > > > > 101 xyz > > > > > // sessions > > > > session_id | userid | session > > > > 999 101 abcdefg > > > > > The server replies back with the session string, "abcdefg". This > > > > string is saved to a cookie on the user's machine through my app: > > > > > Cookie.set("username", "myname"); > > > > Cookie.set("session", abcdefg"); > > > > > Now the user closes the browser, and comes back in a month. They visit > > > > my site. It checks if the above cookies are set. If so, it immediately > > > > calls a different authentication script, passing only the username and > > > > session value: > > > > > onModuleLoad() > > > > { > > > > if (autoLoginCookiePresent() { > > > > autoAuthenticate("myname", "abcdefg"); > > > > } > > > > else { > > > > presentLoginView(); > > > > } > > > > } > > > > > My server still has that session, and considers their login a success. > > > > The same session value persists until the user explicitly logs out on > > > > that machine. At that point I could delete the local cookie, and wipe > > > > that session record from my server database. > > > > > Is the above a reasonable approach.for auto-login? > > > > That's more or less what we're doing, so I'd say yes ;-) > > > > (our app is backed with Alfresco, which manages those tickets (session > > > id) for us, but our client code is more the less the one outlined > > > above) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
