i've got a site, which has a login system.
here's my scenario:
user is not logged in
fills in a form to submit data
before the create action, i check if the user is logged in.
if the user is not logged in, they are prompted to sign up and log in..
upon sign up / login the form is submitted and the form data saved without prompting the user to save it again.
In order to do this, I need to use a redirect_to, specify the controller and action, however, this requires a POST, and I don't believe you can post variables on a redirect.
any ideas of a work around, which would keep the current user flow?
Some options you might want to try:
Perform the user registration using AJAX, so you never have to leave the page and won't need a redirect
Store the form data to a 'temporary' user account, then update the account to 'real' with the user registration info. You may want to occasionally clean out old 'temporary user' data that never completed the registration.
Convert the form data to serialized form and pass it along with the redirect as a url parameter (only works for a guaranteed small amount of data)
Store the form data in the session (last resort, only use if your traffic will remain relatively low, as you may end up running into scalability issues)
Related
I would simply like to ask if I'm doing the things right or if it is better if I stop before going in this direction. I have an administrative area in my website and I though to manage login using a table on my database.
When the user correctly login, I then write on a sql table the username, the session id and the IP obtained from REMOTE_ADDR server variable.
When the user ask for a private page that require to be logged in, I lookup the username on my table filtering by IP and Session ID, this return the user of the current user asking for example for "prices.aspx" page on my admin area.
I have then made my so saved records be deleted after 30 minutes. Is this safe enough? Is this a good way to expose my website to hacks? How could I improve the security?
If your site can be hacked, it doesn't matter how your login system works. What keeps a hacker from getting at your data?
Encrypted Transmissions
Never show database names, file names, passwords in front end code.
2 Step verification login to your website and database
The basic principles of logging a member in, or logging someone in to an authorized page are no different.
Whether you delete a record 30 minutes after it's been saved or not is totally immaterial. If a hacker can access that data, saving it in an unsecured manner for 1 second is to long. If you want the user session to time out after 30 minutes, just deleting the database record won't achieve that. So, to your question, "Is it safe enough?". No, it's not.
If your regular member login is safe, then all you need to do is have a field in your user information database, that indicates whether the user is authorized to see certain pages or not.
When your website is first loaded, don't ever load the admin pages unless it's requested, and then have the user give their password a second time. If the user who logged in is not authorized to see an admin page, then don't even load the HTML that allows a user to request an admin page.
Here is the scenario. I have two objects Users (with username/password) and UserInfo with rest of the data related to user. The Users is an old table with thousands of records and UserInfo is fairly new. I want to get as much UserInfo as I can when the user first logs in.
I'd like to force user to a custom screen after first login and ask for the UserInfo data. Once I get the "required" data in the new screen, I dont show it till the user voluntarily wants to fill in the data under "Profile".
Since there are multiple entry points to the application, I dont want to update all the controllers to check for this.
Is there a way I can use a Spring Security filter or something which is executed on successful login? I had a look at ApplicationListener<AuthenticationSuccessEvent> but it doesnt solve the problem as if I copy paste the link in the browser, it lets me go ahead to the destination without asking for "extra information".
In a nutshell, I want a check after each login which, if fails, user is not allowed to enter the application. No matter how he tries to get in.
In your Config.groovy, configure Spring Security's defaultTargetUrl and tell it to always redirect there:
grails.plugins.springsecurity.successHandler.alwaysUseDefault = true
grails.plugins.springsecurity.successHandler.defaultTargetUrl = '/userInfo/edit'
In your UserInfoController's edit action, you can check that the required fields are present (userInfo.validate() perhaps?) and if they are, redirect to wherever you like, perhaps '/', otherwise render the edit info view.
You can adopt what #doelleri proposed and enhance the rule by those steps:
run a batch task to assign a temporary ROLE_DISABLED role to each user who does not provide supplemental information yet. If the user already had some roles, save them in some property.
setup your authorization rule as that users with ROLE_DISABLED role only allowed to access /userInfo/edit.
in /userInfo/edit, if the user has a ROLE_DISABLED role, render the information input view, and resume user's role after it successfully updated its information. Otherwise redirect to '/' or the path it requested.
Is it safe to login user automatically after registration?
User fills registration form, some info message is sent to his mailbox, and what then:
User redirected to login page asking him for credentials;
OR
User auto-logins as his newly created user?
I feel something not safe enough in auto-login, but can't figure it out!
If they just filled out the login information and you're not concerned about confirming that the email address is legit, then there shouldn't be a problem just logging them in directly.
However, you open yourself up to people/bots creating bogus accounts (at least ones without legitimate email addresses). If you're concerned about that (not sure it this is a public facing app or intranet, etc) then you should at least verify the email address by sending a link with a guid or some identifier that you can track back. Then you can let them log-in once they are confirmed.
You could also just tie it to their StackExchange/Facebook/OpenID/etc account and not make users fill out yet another form and worry about maintaining all that information.
They should need to login. Also the confirmation email should not contain their password. If they managed to give you the wrong email address and you automatically log them in then someone else has access to their account now. This holds even if you have them type their email address twice. Sometimes people make the same mistake twice in a row.
It can be safe to auto login if the user already has an active session as the correct user during the confirmation step. If you think about it, it's not actually "automatically logging them in" but simply keeping them logged in as they was before.
User registers
Keep a session identifying the user
User navigates to the confirmation page (linked in email)
You activate the account
During all that time, there was no reason to end the session. The only reason you would want to end the session (or not create one in the first place) is if your permissions are not properly set to allow someone to login / create a session without giving them higher privileges than an unregistered user.
Now, be sure not to automatically identify the user as X simply because this person navigated to the confirmation page of user X. If a user navigates to this page but does not already have a session open, do not assume he knows the password.
Well, you type username and password in form, hit "OK" button. Then data going to server side and check users database if that user is existed. Then it return user id. And what next?
That data is saved in cookies?
Does it mean, that with every clicked link, site login you to website again?
I mean,
you click some link on site
browser redirect you to that page
site checks your cookies
site grab username and password from cookies
site checks is that data is valid (via connecting to database)
show page to you
Is that correct?
User enters credential.
System validates credential.
Upon successful authentication, server saves user object into session.
System grabs user info from session.
System displays webpage.
Tadaa!! :)
UPDATE
To add a little more...
User visits the secured webpage.
System checks if session contains a user object.
If user object exists in session, allow user through to visit the page.
If user object doesn't exists, redirect user to login page.
You don't need to store user password in the session. In fact, it is highly discouraged. Checking to make sure the user object exists in the session is sufficient.
When the user clicks the logout page, then proceed to invalidate the session... that's it. :)
Almost correct. You rarely go to the database with every request. You usually set a cookie with a expiry date and save the user session and info in memory. So every time a request is made, if the user is not authenticated, you authenticate him, generate and send him a cookie with, say, 5h expiry. So, in the next 5 hours, whenever a request comes in with that cookie, you trust that the user is an authenticated, valid user and you don't have to check the database.
It's not how every site does it nor it is the only way to manage session and cookies but I think it is the most widely used.
You should probably use sessions, but that's pretty much the gist of it. That way the data doesn't accidentally persist.
I mean, for my simple site at home, that's how I do it. But it's still locally hosted, so the security is guaranteed to be crap.
Oh, and no need to check with the database whenever you click on another link -- too much time wasted.
Typically, an application takes advantage of the session that is established between the browser and the web server, and makes a note that that session is "authenticated". "session" is a built in feature of HTTP. If the browser is closed, or after a certain period of time passes, the session is automatically closed. If the user does an explicit logout, the application marks the session as not-authenticated.
how do I prevent my users for more than one simultaneous login per account. I am using Vb.Net SQL.
Just coming from a 'web programmers' point of view, there is one really simple way:
You have to use some sort of central session system, where a Cookie on the user's browser has a hash, or some unique key that is also stored in the database. One each page request, or at set intervals, you check if that hash exists in the database.
Then, whenever you have a user log in, you delete any hashes that are tied to that user in the database, and then you create a new one for the user logging in.
What happens is if a user logs in, and you delete existing hashes from the database, then the other user will be logged out when you go to check for their hash in the database.
Not VB-specific, but: when the user logs in, keep track of the fact they are logged in. You can keep this in a cookie (watching out for the fact that a cookie can be tampered with.) You can keep track of it in a session variable. Or you could keep a boolean field in the database, "is_logged_in".
Then, when the user attempts to log in, you can check to see if they've already done so. If they're already logged in, the script might just return them to the home page (provided they used valid credentials. Otherwise a rogue user could type a username but leave the password blank, and depending on the behavior of your program, could see if a user was logged on at that specific time.)
Also, it is common that when someone is logged in, the webpage itself replaces the "Login" link with some text that says "Welcome, rascher!" and maybe links to their profile or preferences page.
Edit: Also remember to set is_logged_in (no matter how you track it) to "false" if they log out. It might also help to time this out - say, when the user closes the browser, or after "n hours" of inactivity (though that can be really annoying.) It will depend on how long people are generally logged into the system. Also note that someone might log in on their home computer, stay logged in, and then try to log in to the same place from work or their iphone. You might could look at ways of dealing with this (if the IP address is different than the current login, then log the other person out? Or something.)