I have a server with PHP and MySQL. I want to have a login screen where users can enter their email, etc. and then browse my site. What is the best way to keep the user logged in? Ie. they don't have to log in to each page. I have looked into using cookies, and recording their IP address, but I wasn't sure which was best, or if there was a better way?
You can create a cookie based session, whenever the user enters the credentials. The subsequent requests will be having the cookie in the request header, which can be used to identify the user.
link for reference - http://www.opensourceforu.com/2008/12/session-management-using-php-part-1-cookie-based-sessions/
Related
So I have the example-google.php script working, after loging in it throws the default user string has logged in. But my question is how does this protect anything?
Lets say I have //127.0.0.1/example-google.php and I added a href to //127.0.0.1/abc.php after the login is successful.
Well what keeps someone from just typing 127.0.0.1/abc.php? granted I could use $_SESSION to verify that "someone" logged in. But is that going to be enough? Is there a way to re-verify that the user that is trying to access abc.php is truely logged in when thrown from the other page?
Generally, the idea is that you use the session store, indeed.
For example, in my site I have a OpenID login using Steam Community. When a user logs in, after the mode / validate checks etc. from the LightOpenID example, I save their unique identifier in the session store (in this case a SteamID, in your case an email address presumably), then can just use this freely for subsequent requests.
As the session store is server-side, a user cannot impersonate another one without gaining their session cookie (session hijacking is another topic that someone else can go into much more detail on, but I'll give it a shot if requested), but most attacks will be defeated by also storing and validating the requesting IP address.
I keep a couple of mysql tables (one for sessions and one for user information) and store session information in the session table and include a reference to the users table. When a user successfully logs in with their OID provider they are sent back to my site with the confirmation from the provider. I keep track of my user from then on via their session id.
I wipe the session if they choose to log out, but maintain the user info for comments/posts on the site to track who said what.
I actually put a link to "?login={service}" which sends the request to the OID provider and redirects back to that page and on return from the provider it takes the successful login and stores the appropriate information and redirects the user back to the original page where they clicked the "login" button for whichever {service}. You only display the "members only" content if they are verified via OID. You don't create a standard HTML page at abc.php without any sort of way to confirm ID and I think the header redirect is important because it cleans up the URL displayed in the address.
I have a website which has a login/logout feature. How can I ensure, 100%, also in a stable technique, that a user won't be a able to login to the same account from two different computers?
Javascript can't be used for this, since it's easy to disable it.
For example, .NET has a Session_End function that executes when a user aborts the connection with the server. How that can be done with PHP?
Thanks, Guy
Note: This technique would effectively logout the account on the first computer when logging in on a 2nd.
When a user logs in, log the session id for the user to the database or equivalent. On each page request, ensure the session id of the user matches the session id stored in the store for their account. Requests from a logged in account with a mismatched session id should be rejected and the user should be logged out.
It depends on how in depth you want to go. Most commonly:
Create a unique session id cookie on login and saved it in the database
All web pages check the session cookie to make sure it's valid
if the session isn't valid, the user is redirected to the login page
When another user tries to log in, it overwrites the previous session
This essentially kicks out the first user
Large companies will also store the IP address in the database as well (so session cookies can't be stolen)
Note: this question is on where to store login attempts and current login status.
I'm building a web application where users will be required to register to acquire authentication details for which to use when logging in to the system, but I'm a total newbie at security.
And I want a user to login only once per session, so a user must not have more than one existing successful authentication i.e can not sign in from both computer a and computer b at the same time or when already a successful authentication of the same user exists or was not logged out.
I think I need to track the user's location, log in attempts and current log in status; in order to act accordingly.
I'm seeking your advice on what to use between cookies and sessions, how to track the user's location and more suggestions are welcome.
Thank you in advance.
None of these.
You have to employ a database to accomplish your needs.
You have to store the current session id, login attempts and login status in the database.
Dunno what is location though.
While cookies should be used for the authorization itself, to transfer the session id between a server and a client.
The main difference between cookies and sessions is that cookies are stored in the user's browser, and sessions are not. This difference determines what each is best used for.
One should go for cookies to store something that we want to know when the user returns to the web page in future (eg. remember me on this computer check box on login pages uses cookies to remember the user when he returns).
Sessions should be used to remember something for that particular browser session (like the user name, to display on every page or where ever needed).
Good read :
Why you probably shouldn't use cookies to store session data
From what I know, you can not track and compare sessions on the server to check for active connections for the same "authenticated" user. I presume you track your user login and password in the database, and then once they authenticate you set a session variable to track their current login on a given end user device.
The best way I can imagine (aside from regular glitches of disconnects, users not logging off, etc) would be to have a table in your database to track logins and status:
User ID
IP Address (pulled from headers/browser)
last login timestamp (UTC)
Current log in status (boolean)
Last known server session value
Once that is in place you can create contingencies:
log me out from a logged in device if I authenticate successfully again somewhere else by having the server destroy the session stored in the database and replacing it with the new device's active session
check for IP Address upon authentication and either lock out user, or use above method to log out remote session
You get the idea I hope.
how do you check if a user already has logged in?
so that if a user in another browser cant log in with the same account.
also, is this a good solution or should i let the user log in in the other browser and then log out the current user and display a message (you are logged in from another location) just like messenger does?
Using sessions is a good way to do this, and is a very common method for controlling authentication.
The flow usually looks something like this:
User visits site, and session_start() is called. A unique session identifier is set for that visitor (ie. a cookie).
User submits his login credentials to a login form
Login credentials are verified, and this fact is stored in the session data with $_SESSION['logged_in'] = true, or something similar
For the rest of the user's time on the site, you can check $_SESSION['logged_in'] to see if the user has logged in.
In order to control a user's logins, you could simply have a field in a database (users table is fine) indicating what the current session id is (retrieved with session_id()) for the user, and if it doesn't match the cookie value you just received, then you immediately call session_destroy() for that id, and consider the user as logged out.
Using $_SESSION means you don't have to worry about generating your own tokens, and gives you the power of the built-in superglobals to facilitate storing information about the user's authentication status.
Personally, I would allow multiple sessions to be active for a user for most web sites, as there's usually not a good reason not to, but it obviously depends on the nature of the site. However, storing the current active session id as mentioned above is a pretty simple way to accomplish this.
Generate a random token upon signing in (or use the sessionid), and store this in the database and in the users cookie. With each page access, ensure that the users token matches the database entry. If the two don't match, alert the user that they've logged in elsewhere.
You could also store the login time, which subsequently would be the time the token was assigned, and require 30 minutes before permitting another user to login with the same ID.
The first half of the question was answered well with how to detect the multiple users but how to treat them I think still needs a bit of work.
First if a user logs in correctly let them in, don't prevent them if they are logged on some other place. If you really don't want the user to have two open sessions then log out the old one or simply update the session id that you are saving so you can bounce out the old connection. You can inform if you want but I would only message the session that you invalidated. If you message the user logging in it becomes annoying when you are only dealing with the case of a user switching computers and they forgot to log out of the old session.
Well All solutions mentioned above will work but if on every page access you are making a call to database and checking for the session token to see weather its the same token assigned to user .. will kill your response time. what i'll suggest is use a caching mechanism instead of database in above said solutions. storing session token into database will add extra field to your database which is actually not required. Use open source caching solution like memcache.
you can make a table like userLoginStatus with fields like clockIn time & clockOut time,
and insert current time in clockIn when user is do login, leave clockOut time blank at that time, it should be updated only when user do clock over logout button,
so you can check specific user's current status, where clockOut is empty that user should be logged in. because it updated only when user do logout.
Problem: A download link should be displayed in a user's home page.
That download link should ONLY be accessible if the user logged in.
But the real problem is that the user's home page and the download link are on separate web servers.
Is there a way I can send a token with the download link and validate it there?
users server = serverA.com
your server = serverB.org
if i understand it right, the problem is, that the user is only logged in on server A, but not on server B, and there's no way to share the session state (e.g. session handling over a database)?
from the top of my head, i can think of one option:
server B simply asks server A
means: link on serverA contains the users session id*. serverB then asks server A if the session is valid.
you can't do it without communication between those two servers.
* note: instead of the session-id it would be better to use a random token. session ids should not be private.
that won't stop your users to share the url, so if they want someone else to download the file, they can simply pass the url around. on the other hand, a malicious user could also do this with his session-id.
You could make the download link submit a form with the user info to the target server. There are security implications in doing that, because the login info would appear in the source of the page as values for hidden form fields, so perhaps that not the way you'd like to go.
A second option would be to store the session info in a database, and then simply pass the session key to the new server. This would require the second server be able to contact the first server's database and run a query on it. Setting up a username with permissions to login from that server for read access should be sufficient to do that without opening many security holes.
Finally, you could set up a web service on the first server that would return a yes/no answer when given a username, verifying the logged in status of the user. The receiving link on the second server would then take the username and verify the logged in status before building the response.
If the user clicks the link, he is going from his server to your server.
And if he is logged in on your server, then you can do whatever checks you need since he is trying to access the file on your server. Even though the link is displayed on some other server.
That is if you are using sessions to keep the user logged in, it should be enough in the download code to start the session with session_start() and the user should get logged in session he has already.