login | Marcus Povey

If you, like me, have been asked on more than one occasion to write a Facebook login integration for a site, you’re likely to have used the Facebook api library. You also, like me, have had a number of sites that are using older versions of this library which you’ve not had a chance to update – often these libraries are bundled with plugins – for Elgg, the now increasingly ancient “social_connect” plugin is common.

Social_connect, in particular, uses HybridAuth, which is no longer maintained, and itself bundles a rather old version of the Facebook API library.

Anyway, point is, you’ve got some legacy stuff out there. You’ve got the warnings from Facebook about version 2.2 of their API, scanned the changelog and run their migration tool. Today, you’ve suddenly got a bunch of emails from clients saying that the API logins no longer work.

When you take a look, you find that every attempt to log in either spits out an error about no valid User ID being returned or goes into an infinite redirect loop.

How to fix this

It took me a fair amount of digging to track this down, but what has happened is that the API has changed the response format of the request for an access token.

If this was mentioned in the changelog, I missed it. Newer versions of Facebook’s API will handle this, but if you’re using an older version (or rolled your own), you need to change the bit of your code that parses the access token out from the auth code request to handle JSON.

In the legacy Facebook API library, this is found in the method getAccessTokenFromCode() found in base_facebook.php, and you need to replace the following:

$response_params = array();
parse_str($access_token_response, $response_params);
if (!isset($response_params['access_token'])) {
  return false;
}
return $response_params['access_token'];

$response_params = array();

parse_str($access_token_response, $response_params);

if (!isset($response_params['access_token'])) {

return false;

}

return $response_params['access_token'];

with…

$response_params = json_decode($access_token_response);
if (empty($response_params->access_token)) 
    return false;
return $response_params->access_token;

$response_params = json_decode($access_token_response);

if (empty($response_params->access_token))

return false;

return $response_params->access_token;

Hopefully this will result in a less high blood pressure day for you…

Blocking the scripts

Place the following in your .htaccess file, or http.conf for your wordpress site:

RewriteEngine On

RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} /wp-login\.php
RewriteCond %{HTTP_REFERER} ^$
RewriteRule .* - [F,L]

RewriteEngine On

RewriteCond %{REQUEST_METHOD} POST

RewriteCond %{REQUEST_URI} /wp-login\.php

RewriteCond %{HTTP_REFERER} ^$

RewriteRule .* - [F,L]

What this does is block all POST requests to wp-login.php that have an empty referrer, returning a 403 error when this occurs.

It’s very simple, and easy to work around, but seems to block most script kiddies.

Testing

To test, use curl; the following should fail:

curl -d 'test' https://example.com/wp-login.php

1	curl -d 'test' https://example.com/wp-login.php

But this will return some content:

curl -d 'test' --referer foo.bar https://example.com/wp-login.php

1	curl -d 'test' --referer foo.bar https://example.com/wp-login.php

How to fix this

Share this:

Blocking the scripts

Testing

Share this: