I have an app that i use at networking events where users walkup and accept it. It seems that linkedin keeps the user logged in when i pass them through the "accept application" dialog.
Anyone know how to log the user out using code? As this would save me closing the browser everytime to kill the session, which slows down the process greatly.
If you are doing everything server-side via PHP, then you don't need to kill that session, since it's only tied to the token. You just need to request a new token when the next user logs in. If you feel it's more secure, you could just set the token to "" at the end.
If you are doing client-side authentication via Javascript API, then check out:
IN.Auth, IN.Event, and IN.UI
Specifically, the section titled "Log the User Out"
It appears you just need to call the logout method, specifically:
IN.User.logout(callbackFunction, callbackScope)
Where callbackFunction is a function you define that gets called after the session ends, and callbackScope is an optional object that you want to run the callback function on (defaults to the window object).
It also mentions that running the above simply clears the cookies for the session, so hypothetically, if the above didn't fit, you could write a browser-based (which is to say, not running on the domain-restricted page, but in a browser add-on that has full access to all domain cookies) that deletes the cookies when the user reaches a certain page (maybe the thank you page?)
I imagine that would be overkill, however.
Update:
Based on some further reading of how the javascript API works (specifically how the API key that your app has for every request), it looks like the cookie that controls the user's session is tied to your domain, not linkedin (although this is odd, since linkedin shouldn't have access to your domains cookies to confirm that the session is still valid). I'd still use their build in method, but you could also kill the session by clearing whatever cookie they create through your own function.
Related
I have ServiceSite.com (SS) and multiple GameSite.com's. All games authenticate through SS and then log in with their own personal databases. That's all done with a simple JSON API, no need to log into SS to get into a game.
I have the one goal of logging into a game and accessing the features of SS through the game, such as accessing a player's Contact List and Profile, both of which are shared between all games. While in GameSite.com/play, they'll hit a link to ServiceSite.com/contacts and get the response as if they were opening it from ServiceSite.com. I use JSON Web Tokens to manually log the user into SS, to simulate a real login to ServiceSite.com.
This works... so long as they're on the same domain. Meaning, as I'm developing a game, I'll use ServiceSite.com/tempgameurl and any call to ServiceSite.com has no problem establishing and keeping a session. But once the game gets its own domain, or if I'm working on my localhost, I cannot get it to recognize the session on subsequent requests. If I want a response, I will always have to pass the JWT token, which is not suitable for what I'm doing. The goal is to load a game, "poke" SS to create a log in, and then if a player were to visit ServiceSite.com, they would have the session as if they'd logged into ServiceSite.com's front page with their login manually.
In short, I expect that once I hit my first JWT request and make a session on ServiceSite.com from a GameSite.com, that's it, the session is made. But it seems to only actually make a session if I'm requesting from the same domain. I do see it create a session properly, filling in $_SESSION, but that data simply does not persist if the request originates from a non-ServiceSite.com URL.
Sessions and Cookies are domain dependent, it is a browser security issue. You cannot cheat this. However, there is a "trick" you can try, even though it is a bit more complex:
You need to set a cookie for each domain:
authenticate the user, emit a JWT code and create a key=>value type of record in a shared storage (database most likely). The key should be unique, the value should be JWT code and also set an expire time of 20-30 seconds.
in the response HTML you need to make the browser set cookies for the other domains. That can only be done on those domains. So you need to fool it with something like:
<img src="http://anotherDomain/setCookie.php?key=keyFromSharedStorage" style="display:none;" />
in the setCookie.php, check the shared storage and retrieve the JWT based on the $_GET['key']. Then set a cookie with that JWT.
You could pass the JWT directly, but passing a key that expires fast should be more secure. Add an image for every domain.
Instead of a cookie you can create a session on each domain. Same principle really.
Well try saving your needed data and sessions in database itself. It seems to be small amounts of data and logs.
After a game save the sessions on the database and open from whichever place you are at.
I'm in the process of setting up various authentication methods on a project I'm working on, and the common OAuth 2.0 framework that Google and Facebook use seems pretty awesome. Reading the example Facebook gave though, I stumbled across something that seemed strange to me.
If you look at the bottom of that facebook page, you can see an example in PHP. In their process, they first set a random string to $_SESSION['state'], then redirect the user to the facebook authentication page, which then sends the user back to the original page, where they compare the state string to what's supposedly stored in the session variable. Maybe I'm missing something here, but don't you lose all session data if the user leaves your site? How does this work? How is your session data maintained even though you leave the site?
The session data stays until you close the browser or logout from your app. The session state could be getting saved on the server or on the browser in a cookie. Either way, the session data is available to you once facebook redirects back to your site.
You don't lose your session data, when user leaves your site.
So, we check state value after user is redirected back to our website from facebook.
I have found that after a certain amount of time, the Facebook session that is created using the Javascript SDK, expires. I appreciate that the session cannot live forever but is there a way to keep a user logged into my site indefinitely, unless of course they log out of Facebook?
I use the Javascript SDK in conjunction with the PHP SDK and I am finding it very hard to figure out a solution to this.
If the session does not exist then PHP cannot detect the user and therefore my site thinks they have logged out, when in fact, the session has simply expired and they just need to refresh the page to allow the Javascript SDK to regenerate the session. The reason why I need to sort this so desperately is simply because the user will see a page saying that they are not logged in, when in fact they are. All they need to do is refresh the page to send the new session to the PHP SDK
A page refresh via javascript is not a solution here as this happens too frequently and it does not look good loading half a page and then automatically refreshing
Is there anyway around this?
UPDATE
I have found an article that refers to something called 'offline_access', could this be the answer? Can I still post things using this?
Use the "offline_access" permission to extend the life of your access tokens and thereby make your sessions live forever (or until it is deprecated in May).
from Facebook Extended Permissions
Enables your app to perform authorized requests on behalf of the user
at any time. By default, most access tokens expire after a short time
period to ensure applications only make requests on behalf of the user
when the are actively using the application. This permission makes the
access token returned by our OAuth endpoint long-lived.
I am struggling to keep the Facebook session alive using PHP on my website.
I use both the JavaScript SDK and the PHP SDK to form the basis of my app.
The problem I am having is that when the "Facebook session" ends, my PHP script believes that you are logged out of Facebook. But, as soon as I call the FB.init() using the JavaScript SDK, the session comes back to life.
Is there anyway to achieve the same using the PHP SDK? Or can I set a custom expiry time on the Facebook session?
Extracted from comments
It seems that the session expire time is set to 2 hours but I am not certain about this. I don't think calling the PHP api will make a difference. I need to explain a little clearer what is happening. Basically, if you arrive at my home page, you get the option to login via Facebook. If you do, this all works fine! Once you are logged in and you have authorized the app, this is okay until the session expires. When the session expires, it seems that the PHP SDK is unable to determine whether or not you are logged in via Facebook, however, the Javascript SDK is. I use getUser() for the PHP SDK.
In other words, because the session has expired, PHP thinks that you are no longer logged in via Facebook. The Javascript SDK is able to detect whether or not you are logged in, regardless of whether the session is there. When it realises you are, it recreates the session any way. But in order for the session to be picked up by PHP, the page obviously needs to be refreshed. This is the problem I have, because the page displays content based on your Facebook login, I need the PHP SDK to be able to recreate the session as well, so that it is not necessary to refresh the page.
Ok... Not to sure what the exact details of why your session are acting like this - I must state too that I am not very well versed in PHP sessions and have not has extensive experience with them.
My suggestion would be to let the JavaScript SDK do its work... let it "re-detect" your session successfully and after it has done so, make an AJAX call to your server. In the processing of that call you can create and re-initiate the PHP SDK hence reviving your session.
Additionally you could call the FB.getAuthResponse periodically to ensure that the users session is still valid ( at least in the JavaScript SDK ).
From the Fb.getLoginStatus() documentation :
{
status: 'connected',
authResponse: {
accessToken: '...',
expiresIn:'...',
signedRequest:'...',
userID:'...'
} }
By testing for the presence of the authResponse object within the
response object, you can be sure the user is known to your app and you
can begin to make further calls to the Facebook APIs. If the
authResponse object is not present, the user is either not logged into
Facebook, or has not authorized your app.
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.