I'm trying to implement Facebook authentication into my web project. I've managed to get login working just fine, but I am unsure as to how to proceed further.
I need to continuosly make sure that the user is logged in and authenticated while using my application. In previous projects I've achieved this by storing userid and password in cookies and run a check against the mysql "users" table each time a php page was called.
I haven't found any tutorial which describes how to do this with Facebook, as all the tutorials ends after login is complete.
I'm thinking of storing the FB_UID in a php session variable, and then check it against the mysql "users" table to see if it's correct each time a php page is called. However I get a feeling that this is unneccessary, and that the FB session variables can be used for this purpose. Any thoughts or insights appreciated!
I will of course implement https when the site goes online due to php session security issues.
When the user login to his/her facebook account, authenticate that use against database (check username, password, ...). If they match, create session(s). From that point use session for the authentication.
With the above way, people can hijack session. Enabling cookie can prevent it.
I hope that helps.
You can use FB.Event.subscribe() call. From the website:-
Global Events to which you can subscribe:
auth.login - fired when the user logs in
auth.authResponseChange - fired when the authResponse changes
auth.statusChange - fired when the status changes...
While authenticating a facebook user, if the FB_UID matches your users table, have a php session variable store the FB_UID and check if the php session variable is set or not, every time the page loads. Finally when the user logs out, unset the php session variable.
Related
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)
I want to allow users to use only one system to login.
if they use another machine then they should not be able to login.
If they want to login then they can click request login option which will sent a reset link to the users email which when clicked will reset and update the database so that from now on he can login form that machine form which he made the reset request.
so, when ever the user changes his machine he should not be able to login and can request a reset option.
i am using ip and session id and previous session id to check login from one machine.
if his session expires in that machine he will be logged in next time by storing the previous session id reference in a cookie.
so each time he access there will be two cookies to mean that whether he previously logged in this machine and if so then the session id is updated and he is logged in.
so if he is login in from a machine and if there is no previous/current session-id/ip-address then he is considered totally new to that machine and he cannot login.
Hope i have made it clear. if it is not much clear then please comment then i will edit my question.
I want a better approach or some other efficient mechanism to implement such functionality.
Even if the client is in a lan all the above conditions apply.
do my way of doing this has complications? if so then please suggest a good one.
Thank you.
Editing after a comment from https://stackoverflow.com/users/164394/purplepilot
the user can login anywhere but if the machine changes they can request an reset through their email. when they click the link in the email then that machines ip will be recorded and the user will have to continue in that system. This was requested by the admin cause there is going to be only two admin users.
Why dont you use cookie instead of session as your app demand that.
i think you are confused
Session never stored in client , cookie does. so you have to think about cookie for this app. Logic for the project seems okey once you implement cookie instead of session.
I am developing the user management portion of a website that will host a webcast. The goal is to prrevent the same user nam (email address) from being used concurrently. That is, we don't want two individuals using one login to view the event.
I've already setup a table that holds the user registration data with regID as primary key. My thought is to create a login history table with username as primary key, foreign key to user name in registration table. The login history table would simply timestamp when the user logs into the site. However, this won't accomplsih my goal of preventing more than one individual from using the same login name.
Instead, would it be better to have a login status field either in the login history or user table that is set to 1 for logged in and 0 for logged out? It would need a stored procedure to update the value at login and at logout, and would need to be validated when a user logs in such that if login status = 1, user already logged in and cannot login a second time. Is this a feasible approach?
Please share other methods you've used to prevent the same login credential from being shared amongst multiple individuals.
Thanks,
Sid
If it is OK to logout an already logged in user if someone else logs in with the same credentials then you could do the following: when a user logs in generate a random ID in your database for that user and the same in a cookie session. The two must match to authenticate.
Without rolling your own session handler, you could do a little parallel tracking. When a user logs in, you can store the user's session ID and login time in the database (maybe inside the user information table). The login script could then check for the existence if this sessionID and allow/deny login based on the presence of the session ID. If the ID's null/blank, then the user logs in. If there's a session ID present, and it's more than X minutes old, allow the login. Otherwise deny them.
Of course, you'd probably want to roll your own session cleanup handler at that point, so that when stale session files get deleted, you can remove the associated IDs from the database at the same time.
The problem here is detecting the user is logged in (i.e. whether he didn't logout).
One possible way is to register in the database the time of his last activity and the time of his explicit logout. You could then deny a login if it this was attempted less than say 5 minutes ago relatively to his latest activity and if he didn't login in between.
You could force "activity" by having the website pages periodically poll the server with Javascript.
It's easy to determine when someone logs in. It's much harder to determine when someone logs out. If you have a mechanism of killing the webcast streaming to a particular user quickly, you might want to have something which pops up asking the user if they want to kill their other session if you think there might be one active.
How are you doing user sessions on the server? If you store them in the db, you could query the active sessions anytime someone attempts to log in and see if they're already in there. Of course you'd probably also have to check some kind of timestamp since you're not guaranteed that sessions will disappear at session.gc_maxlifetime.
You might want to consider making a global variable in php to store a hash array with login status. This has the benefit that if the application has to be restarted for some reason, the user isn't stuck in the wrong state in the database.
You can store a mapping from user ID to IP or session cookie and redirect requests that come with different information to the login page. If the user logs in, the other session would be invalidated and further requests in the last session forward to the login page.
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.
I'm using the Facebook Connect API for the login system on a website built using PHP. There is no straightforward way to determine if a user is logged in.
$fb = new Facebook($api, $secret);
$fb->get_loggedin_user();
The above function always returns a user id, once a user has authenticated with the site, even if they sign out of Facebook, it still returns their user id.
I've worked on this for a while, and after looking around, I think the reason it does this is because when a user is authenticated on the site, the Facebook JavaScript API stores cookies that are used to save information about the session.
However, if the user signs out of the regular Facebook session, the cookie is still returning values ,even if the session is no longer valid.
My question is how do I update the cookies so that they don't give me values when the session is no longer valid?
This can be a bit tricky. Basically Facebook stores a bunch of cookies on the user's browser that are namespaced to your application id (ie. 12345_fb_sig=etc). These cookies are used to tell your FB Connect app that the user has logged in to Facebook, and pass along the facebook session id. But if the user goes somewhere else and logs out, these cookies don't get cleared, and as far as your Connect site is concerned, the user is still logged in. If the user comes back later and you try an API call with that session key, it will fail.
You can clear these cookies from a server-side library call to the PHP FB API client, $facebook->api_client->clear_cookie_state(), however, I wouldn't recommend this method. It requires you to make some kind of API call on each page load in order to confirm that the session key is still valid, and that adds a lot of overhead.
Generally, the best way to handle this is with the FB Javascript libraries that you're already utilizing for FB Connect. You can add a parameter to the FB.init() call used to set up FB Connect that will force a page refresh if the client's session state has changed:
FB.init("<YOUR-API-KEY>", "<YOUR-CROSS-DOMAIN-CHANNEL-URL>", {"reloadIfSessionStateChanged":true});
It's a bit inelegant, as the user will see a page reload happening, but it's likely the best way to be sure. I would highly recommend you check out the Detecting Connect Status wiki page for more on these techniques.