I'm using Facebook as an option for logging into my website, and then am doing Graph API requests on behalf of them. I'm upgrading to both the new JavaScript SDK and the PHP SDK to use their latest oAuth stuff before the October 1 deadline.
The PHP SDK now comes with an abstract BaseFacebook
and they have an example Facebook
class implementation that relies on PHP $_SESSION
s. I run a pretty large multi-server website, which makes using $_SESSION
s tricky -- can't use the default file-based sessions, and database-backed sessions often are no good for performance reasons. Not sure I want them in Memcached either as users shouldn't get logged out if it's cleared, etc.
The concrete class only needs you to persist these 4 fields for each visitor: state
, code
, access_token
, user_id
. It seems like not all of these really need to be pure $_SESSION based. I'm trying to determine what really needs to go where...
state
data seems like it can be stored in a client-side cookie as it's only 1-time use for CSRF prevention. code
really need persisting or is it only used once?user_id
and access_token
be stored in my users
MySQL database? If so, how do I identify who a Facebook-authed user is to login them in, using the fbsr_
cookie?I'm happy to store some stuff in the database as long as it's clear that it's only be accessed when necessary (not on every page request for logged out users).
Basically: Is it feasible to authenticate FB users without using $_SESSIONs? Where by "sessions", I mean some PHP-set cookie for all visitors (logged in or not) that links them with server-side data.
I made some changes in Facebook.php file from PHP SDK. Just changed all functions to work with cookies instead of $_SESSION.
// $_SESSION[$session_var_name] = $value;
setcookie($session_var_name, $value, time() + 3600, '/');
etc
and commented out session_start code:
//if (!session_id()) {
// session_start();
// }
This is simple solution and it works perfectly.
You are correct about state
and code
, they are for one-time use during initial authentication and do not need to be persisted to other pages.
Userid can be stored in the database, and often is done so as a permanent entry. Access_token can be stored in the database, but of course it is not a permanent value and will have to be refreshed often. But it can be a way to avoid using sessions or cookies as long as you have some other way to identify the user so you can pull the token from the db.
I have never been crazy about the idea of using PHP sessions for Facebook apps anyway, for reasons of cookie (un)reliability. You might want to take a look at http://www.braintilt.com/fbcookies.php for some ideas about avoiding the dependence on sessions that most Facebook examples are filled with. Of course if you're not adverse to cookies you can set your own and just use that to propogate the user identifier, rather that the GET/POST methods outlined there.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With