Facebook breaks logins
developers.facebook.com
developers.facebook.com
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.
To me as both an app user and developer, single sign on feels like the Right Thing To Do. I'm sick of running through the same sign up flow for every single service I use, like a hamster wheel. Maybe the solution isn't fb, it's some kind of apple or google SSO? Why aren't AAPL and GOOG pushing their own SSO hard on the mobile ecosystems they control?
The solution is definitely not Facebook, Google, or Apple. They all plugged SSO into an existing platform and allow developers to perform actions on my behalf with the same credentials. Sadly, Microsoft's Passport.net was the closest anyone has gotten to a real solution because they treated their own properties as just another consumer. They killed that by trying to tie it directly into your Windows login which are inherently insecure.
because neither of them has a controlling amount of the required market (which is basically the entire internet!).
Mozilla has a project called persona (http://www.mozilla.org/en-US/persona/), which aims to solve this by splitting the login from verification and authentication, but preserves privacy (unlike oauth). If vendors of services can give up their desire to control the userbase, this could be the solution.
A lot of people have 6yo+ facebook accounts. I quite enjoy the fact that my verified facebook email goes to a dead account that I only monitor on a 6 month basis... it saves me from a ton of spam.
A pet peeve of mine is when I click on the login with facebook button and the site still makes me fill out my name, username, email address, and set a password. So what's the point of logging in with facebook?
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.
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.
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...
Also, why is there no salt in the comparison. It calls a naked crypt, that whole ... interesting ... hash() function is sitting there unused.
I have serious doubts whether this code actually serves the user's interest - despite trying to be cute and helpful
1. When user registers, his password is hashed with that hash-function, and that hash is stored in a database (it uses random salt).
2. When user tries to access the site, a password is hashed against the hash stored in a database, and it should return same hash if matched (this is how crypt works!).
3. In non strict mode we try also two different passwords to match the hashes (just like Facebook does).
Code example:
1. $hash = \password\hash('user entered password'); // store it to db
2. retrieve hash from db, and check it:
$valid = \password\check('user entered password', $hash, false);
3. // Now these passwords are valid:
'user entered password' // == correct form
'User entered password' // == Mobile browser capitalizing first char
'USER ENTERED PASSWORD' // == CAPS LOCK on
And one line example:
$valid = \password\check('user entered password', \password\hash('user entered password'), false); // == true
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"]
I've worked with both and Instagram is… pretty straightforward. Granted, I only ever authenticated and consumed feeds, but still.
Facebook on the other hand is a maze of twisty little passages, all alike
* OAuth redirect_uri is locked to a single domain. No test.example.com/staging.example.com for testing - you need to create a new app for a testing/staging environment.
* Max of five apps in an account (see above) - we're having to register an Instagram account per app so we can create dev/test versions of the app.
* Can't grant access to other devs for an account.
* Access to the commenting API is whitelist based. API gives an e-mail address, which never responds. Trying to use the API returns JSON with a bitly link to a Google form, which also never responds. We've been waiting some time for them to respond with a yay/nay on comment whitelisting.
* Docs say you should respect privacy setting of photos, but API doesn't tell you which photos are private anywhere.
* The Google Group seems to be a place feedback/bug reports go to die.
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.