Allowing users to log in to your application using Facebook is quite common. It can be easier for users. It can give you access to demographic data with less work. But the API can die, change, or act generally unpredictable. And you have zero control over it.
This particular issue is impacting 9gag, Pinterest and others. Whilst many of these sites support user logins without Facebook, just as many of them don't. Imagine if tomorrow Facebook charge to connect to their API or there's some extreme exploit. How much damage would your application face?
[1]: http://techcrunch.com/2011/08/11/facebook-wins-worst-api-in-...
This way, if facebook ever down (or removes their services), you have an _out_ for your users to login via the traditional username/password.
Then why are they bothering to sign in with facebook at all? It is now a more involved process than simply signing up with email/password, which is what facebook logins are supposed to be for avoiding.
But it's also the price you pay if you want to tap into their user base. So it is what it is. You just have to keep your head on a swivel. shrugs
It is? The facebook userbase is entirely and completely unwilling to sign up with a password? Putting a facebook login button on your site doesn't tap into facebook's userbase. If you want to try to tap into their userbase, you need actual integration with facebook, which can be done even though you had them sign up using a password. That way they can still use your site when facebook fucks up, and only the "automatically spam my friends" stuff stops working.
I'm yet to see a very well done API.
Edit: Here's a post on the matter http://www.zdnet.com/blog/facebook/facebook-passwords-are-no...
* "pAssword" - the password as it is
* "PaSSWORD" - the password, case inverted, in case you have caps lock on
* "PAssword" - the password with its first letter capitalized, for those with mobile devices that insist on Capitalizing Everything.
Something inline this: https://github.com/bungle/web.php/blob/master/password.php#L...
One way to resolve that issue is to create two versions of the password (one with normal casing and one with inverted casing, but both with the first character lowercased), sort them, and pick the first result.
["pAsSwOrD", "PaSsWoRd", "PAsSwOrD"].map(function canonicalize(pwd) {
function invert(str) {
return (str == str.toUpperCase()
? str.toLowerCase()
: str.toUpperCase());
}
var head = pwd.substring(0, 1).toLowerCase();
var tail = pwd.substring(1);
var vers = [head + tail,
head + tail.split("").map(invert).join("")];
return vers.sort()[0];
});
["pAsSwOrD", "pAsSwOrD", "pAsSwOrD"]
fb_options[:client_options] = {
:site => 'https://graph.facebook.com',
:authorize_url => 'https://www.facebook.com/dialog/oauth',
:token_url => '/oauth/access_token'
}
provider :facebook, api_key, secret_key, fb_options> (according to) Andrew Fowler (from the comment thread on facebook)
The solution is to replace your OAuth Dialog URL: "https://graph.facebook.com/oauth/authorize?...... with the up-to-date URL: "https://www.facebook.com/dialog/oauth?....... They removed support for some parameters without fixing the redirect from their old endpoint.
Maybe if you worked with the Facebook login system / followed their API frequently it would have made sense. For someone who once integrated Facebook logins into their site it felt a little bit cryptic.