Automatically login newly registered users
I'd like to have newly registered users either logged in immediately or logged in after clicking a link on an email comfirmation. I can't find in the spec (I don't want this to be specific to an application server) how to do this.
Ideally, I have a login page that includes a section for new users. When a customers requests a protected page, they are redirected to this login page where they can fill out their new user registration. They'll click submit and be directed to another page that asks them for the confirmation code emailed to them. They then enter this code and finally they are automatically redirected to the original protected page they asked for.
How should I go about implementing this? I'm fine without that email confirmation part too. If I can just have a newly registered user added to our database and then automatically logged in and forwarded to the originally requested protected page, that's good.
# 1
Store the username and password temporary in the session along an unique activation key and add this activation key to the link. Like http://example.com/activate/bf1256f101e0969b7caa340c177ae093
This is only possible if the session hasn't expired, it would be a security hole otherwise.
> I'm fine without that email confirmation part too.
Without email confirmation just follow the login procedure as you already have programmed.
# 2
Hi BalusC, thank you for your response. Though I'm afraid I don't understand it :(. Hmm... just read it a few more times now and I think I get what you're saying. Though what I'm looking for is a way to automatically login a user after registration. Currently, I can register a user easily enough. They enter user/pass/details and I store that in the database along with an entry in the roles tables. However, now after they're successfully registered they have to go back and login with their new registration information. I don't want them to have to register and THEN login. I want them to register and automatically be logged in after that.
# 3
Like BalusC mentioned, just store the information ( userid etc ) of the newly registered user in the session like you would do for someone who had just logged in.Except now you seem to not want the activation so you can skip storing that in the session; atleast for the time being.
# 4
I do still want the email activation. But the core critical component I don't understand how to do is log a user in. Normally, I set the security-constraint element in my web.xml file to redirect a user's webpage request to the login page if they aren't logged in or aren't a part of the necessary role. They enter their credentials, get logged in and get redirected to their requested protected webpage.
That all works great and is easy enough to set up. Now how do I programmatically log a user in instead of having the servlet engine do it for me? How do I say, this session I want to be considered logged in as this user?
# 5
Oh. I don't think you can bypass the login of the webserver; not sure though.
But what you could try is to redirect to j_security_check ( if you're using Tomcat ) with the required parameters ( j_username and j_password ) as part of the request. Though you should obviously not put them in a query string!
I guess after the user registers, redirect to j_security_check with the values he/she's just registered with and that should work?
# 6
Oh, you're using HTTP based authentication. No, then you can't login an user from the server side -afaik.
I was thinking in the context of a form based authentication, because letting the users registering and activating accounts is generally only applied in form based authentication solutions.
# 7
> I was thinking in the context of a form based
> authentication
@BalusC; but isn't he talking about FORM based authentication too? He says:
>redirect a user's webpage request to the login page
>if they aren't logged in
So if there's a login page and not a BASIC type dialog box, then it must be FORM based, mustn't it?
# 8
I apologize, I should've made it more clear from the beginning I was referring to form based authentication from the servlet engine/container. No, I'm not using basic authentication, I'm using form based authentication.
nogoodatcoding, you have a good idea about redirecting to the j_security_check "page". Though I don't have their user/pass. Well I have their username, but their password is encrypted. I guess I have the option of storing unencrypted passwords. But then will the user automatically get redirected by the servlet engine to the correct webpage they originally asked for? Can I change that?
very surprising to me there isn't a straightforward and simple way to do this. I have to imagine MOST projects would want to programmatically log someone in after registration/activation.
# 9
But during registration you already have the username and password. Just store it in session along an activation key. It doesn't matter if the password is one-way encrypted (this is just good practice). As long as the encrypted password matches the for the given user stored password in the database (which ought to be encrypted too), then you're fine.
It just looks straightforward to me. Maybe you're thinking the hard way and/or overlooking the simple things.
# 10
That's true, ok, so assuming I don't do an activation email or they activate their account within the same session, then I can store their password in the session. Not ideal security, but less risky than storing unencrypted passwords in the database.
Ok so I'll try nogoodatcoding's redirect security check. See how that works. Now is it defined in the spec what happens if I post to the j_security_check "webpage"? Will it, if successful login, redirect to the originally requested webpage?
# 11
I'm trying nogoodatcoding's suggestion to post to the j_security_check servlet after a redirect. How do I do this? Several articles I googled suggest this is impossible. Browsers only redirect GET requests. Is there a way? I can't want to redirect with a url that contains the user/pass. Even if that would work...
# 12
I don't really remember what I'd read about FORM logins, from a few months back since I've only worked with BASIC authentication.
But I vaguely recall there being something about not being able to call the login page directly otherwise it won't work and stuff like that. It has to be managed by the server. Or something.
But I did manage to do something, dunno how secure a method it is ( maybe BalusC can comment? ) or how much it'll help you....
1. On a random page ( you would probably do this in the servlet/ JSP where the user would normally reach after registering ), I put my username and password into the session ( this is where the security is flawed I guess )
2. I made that page redirect to the secured resource.
3. Step 2. would cause Tomcat to redirect the user to the login page.
4. On the login page, I check if I already have some values in the session ( which would indicate a newly registered user ), I put those values as the values for the j_username and j_password fields in the JSP code and then remove them from the session ( so that they don't just hang around after I'm done using them )
5. In the HTML page's onLoad() event, I call a JavaScript function which checks if the j_username field has some data. If not, it's a freshly loaded page where the user is still to enter data. If yes, then it's been populated programmatically by my JSP code with the newly registered user's username/password combination, and I call the form's submit() event which then automatically calls the j_security_check 'servlet' and performs the login.
A. Yes, it's a very messy way and probably not very secure.
B. It depends on JavaScript.
C. You could probably encrypt the userid/password while putting in the session and then decrypt when populating the login page fields.
This is what I've got working and I'm sure it can be improved upon!
# 13
Oh man that's ugly. I mean I like the way you think to work around the situation and can't think of a better way. But I don't think I can use this as a solution. 1 major problem is that the user/pass are now in the webpage and potentially in the searchable browser cache. Actually, if that problem wasn't there this would be good enough for me to use.
One change I would make would be for the login page to immediately, before displaying anything, check for the user/pass in session. If exist, then display a blank login page that has a javascript submit function with the j_username and j_password fields as hidden variables. That way the user isn't confused with a flashing login page and it makes the automated login a little faster/smoother.
