7 ms·

Facebook breaks logins

117 points by apoorvamehta 14y ago

bleonard 14y ago
For omniauth/rails people out there, we found this to work. 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
- mpd 14y ago
  This looks to have resolved it for us as well. Thank you.
- hayksaakian 14y ago
  The explanation: > (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?...... https://graph.facebook.com/oauth/authorize?...... with the up-to-date URL: "https://www.facebook.com/dialog/oauth?...... https://www.facebook.com/dialog/oauth?....... They removed support for some parameters without fixing the redirect from their old endpoint.
Smerity 14y ago
This is a good time to remind ourselves: Facebook's API is a service and can be a single point of failure for your business. Unlike AWS, you don't even pay for it and it has a history of being problematic[1]. 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-developer-survey/ http://techcrunch.com/2011/08/11/facebook-wins-worst-api-in-...
- chii 14y ago
  You can get the best of both worlds by making it so that your user (has to?) also set a password when they finish logging in via facebook the first time. This way, if facebook ever down (or removes their services), you have an _out_ for your users to login via the traditional username/password.
  - pidge 14y ago
    You don't even have to make them set a password when they first register - just verify their email address and handle setting a password though the usual forgotten-password flow if you ever need to.
    - filip01 14y ago
      Why even verify their email address? It's already been done by Facebook?
      - engtech 14y ago
        Verify they still have access to that email. 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.
    - dsl 14y ago
      Remember when they changed everyones default email to be username@facebook.com? Yeah, thats pretty much all you're going to get from the API.
      - rohamg 14y ago
        A) not true, the API releases "primary email" which is usually NOT facebook. and B) even if it were that's why you check and verify: if u pull a @fb address don't save it, just prompt the user. 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?
thathoo 14y ago
Yep, that worked for me: added this in devise.rb: config.omniauth :facebook, FB_APP_ID, FB_APP_SECRET, {:scope => '.....', :client_options => {:ssl => {.....}, :display => 'popup', :setup => true, :site => 'https://graph.facebook.com https://graph.facebook.com, :authorize_url => 'https://www.facebook.com/dialog/oauth https://www.facebook.com/dialog/oauth, :token_url => '/oauth/access_token'}}
edouard1234567 14y ago
seems fixed.
contingencies 14y ago
http://imgur.com/V5LD0EB http://imgur.com/V5LD0EB
supervillain 14y ago
I wonder if Facebook stores it's password in clear-text, since you can login with either 'Password' or 'password', does it hash the first character and the rest into 2 different hashes? If not, we have a our passwords in readable form in their database that have huge privacy and security issues.
- ohwp 14y ago
  Or they just make everything lower- or uppercase before checking it against the encrypted version.
  - rmc 14y ago
    Almost certainly not, since this would reduce the entropy of their passwords, making brute forcing easier.
- switz 14y ago
  They hash it once and save it to the database. When logging in, they generate three hashes (if I remember correctly) and compare it to the hash in the database. If any match, it logs you in. Edit: Here's a post on the matter http://www.zdnet.com/blog/facebook/facebook-passwords-are-not-case-sensitive-update/3612 http://www.zdnet.com/blog/facebook/facebook-passwords-are-no...
- pidge 14y ago
  It's more likely that they coerce to lowercase the the first letter of the password you put in and then store/compare the hash of that resulting plaintext. They could even transparently upgrade passwords created before they started doing this by using the plaintext from the next time you login successfully to regenerate the hash.
  - buddydvd 14y ago
    Lowercasing the first character--by itself alone--does not address inverted case scenario (e.g. "PaSsWoRd" and "pAsSwOrD" evaluate to "paSsWoRd" and "pAsSwOrD" respectively). 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]; }); Which gives the following result: ["pAsSwOrD", "pAsSwOrD", "pAsSwOrD"] The three different variations get canonicalized into one version. With it, you can just store one hash instead of three.
sutro 14y ago
Is the United Breaks Guitars guy available?
aidos 14y ago
I have to admit that I sort of struggled to understand what Facebook were trying to communicate to me when that message popped up on my account. 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.
- henrikschroder 14y ago
  I've done way too much work integrating Facebook login and payments, and their error messages never make sense. You just have to learn how to map their undecipherable gibberish into actual errors, and then go fix it.
alex_c 14y ago
I was having lunch recently with a few developers, and the topic of "What is the worst API you ever had to work with" came up. The unanimous answer was immediately "Facebook". Everything from the documentation, to multiple ways to do similar things (each of them incompletely documented), to deprecations that never actually go away, to arbitrary breaking changes.
- ceejayoz 14y ago
  I'd go with Instagram's over Facebook's.
  - phillmv 14y ago
    What did you try to do? 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
    - ceejayoz 14y ago
      Pain points we've run into: * 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.
joebeetee 14y ago
It's still broken for mobile web
- joebeetee 14y ago
  http://developers.facebook.com/bugs/ http://developers.facebook.com/bugs/ is broken as well if you are logged in. Big bug.
jhaile 14y ago
Does anyone know if there is a workaround if you are currently using the FB.login method to authenticate users?

117 points by apoorvamehta 14y ago

For omniauth/rails people out there, we found this to work. 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

mpd 14y ago
This looks to have resolved it for us as well. Thank you.
hayksaakian 14y ago
The explanation: > (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?...... https://graph.facebook.com/oauth/authorize?...... with the up-to-date URL: "https://www.facebook.com/dialog/oauth?...... https://www.facebook.com/dialog/oauth?....... They removed support for some parameters without fixing the redirect from their old endpoint.

Smerity 14y ago

This is a good time to remind ourselves: Facebook's API is a service and can be a single point of failure for your business. Unlike AWS, you don't even pay for it and it has a history of being problematic[1]. 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-developer-survey/ http://techcrunch.com/2011/08/11/facebook-wins-worst-api-in-...

chii 14y ago
You can get the best of both worlds by making it so that your user (has to?) also set a password when they finish logging in via facebook the first time. This way, if facebook ever down (or removes their services), you have an _out_ for your users to login via the traditional username/password.
- pidge 14y ago
  You don't even have to make them set a password when they first register - just verify their email address and handle setting a password though the usual forgotten-password flow if you ever need to.
  - filip01 14y ago
    Why even verify their email address? It's already been done by Facebook?
    - engtech 14y ago
      Verify they still have access to that email. 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.
  - dsl 14y ago
    Remember when they changed everyones default email to be username@facebook.com? Yeah, thats pretty much all you're going to get from the API.
    - rohamg 14y ago
      A) not true, the API releases "primary email" which is usually NOT facebook. and B) even if it were that's why you check and verify: if u pull a @fb address don't save it, just prompt the user. 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?

thathoo 14y ago

Yep, that worked for me: added this in devise.rb: config.omniauth :facebook, FB_APP_ID, FB_APP_SECRET, {:scope => '.....', :client_options => {:ssl => {.....}, :display => 'popup', :setup => true, :site => 'https://graph.facebook.com https://graph.facebook.com, :authorize_url => 'https://www.facebook.com/dialog/oauth https://www.facebook.com/dialog/oauth, :token_url => '/oauth/access_token'}}

edouard1234567 14y ago

seems fixed.

contingencies 14y ago

http://imgur.com/V5LD0EB http://imgur.com/V5LD0EB

supervillain 14y ago

I wonder if Facebook stores it's password in clear-text, since you can login with either 'Password' or 'password', does it hash the first character and the rest into 2 different hashes? If not, we have a our passwords in readable form in their database that have huge privacy and security issues.

ohwp 14y ago
Or they just make everything lower- or uppercase before checking it against the encrypted version.
- rmc 14y ago
  Almost certainly not, since this would reduce the entropy of their passwords, making brute forcing easier.
switz 14y ago
They hash it once and save it to the database. When logging in, they generate three hashes (if I remember correctly) and compare it to the hash in the database. If any match, it logs you in. Edit: Here's a post on the matter http://www.zdnet.com/blog/facebook/facebook-passwords-are-not-case-sensitive-update/3612 http://www.zdnet.com/blog/facebook/facebook-passwords-are-no...
pidge 14y ago
It's more likely that they coerce to lowercase the the first letter of the password you put in and then store/compare the hash of that resulting plaintext. They could even transparently upgrade passwords created before they started doing this by using the plaintext from the next time you login successfully to regenerate the hash.
- buddydvd 14y ago
  Lowercasing the first character--by itself alone--does not address inverted case scenario (e.g. "PaSsWoRd" and "pAsSwOrD" evaluate to "paSsWoRd" and "pAsSwOrD" respectively). 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]; }); Which gives the following result: ["pAsSwOrD", "pAsSwOrD", "pAsSwOrD"] The three different variations get canonicalized into one version. With it, you can just store one hash instead of three.

sutro 14y ago

Is the United Breaks Guitars guy available?

aidos 14y ago

I have to admit that I sort of struggled to understand what Facebook were trying to communicate to me when that message popped up on my account. 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.

henrikschroder 14y ago
I've done way too much work integrating Facebook login and payments, and their error messages never make sense. You just have to learn how to map their undecipherable gibberish into actual errors, and then go fix it.

alex_c 14y ago

I was having lunch recently with a few developers, and the topic of "What is the worst API you ever had to work with" came up. The unanimous answer was immediately "Facebook". Everything from the documentation, to multiple ways to do similar things (each of them incompletely documented), to deprecations that never actually go away, to arbitrary breaking changes.

ceejayoz 14y ago
I'd go with Instagram's over Facebook's.
- phillmv 14y ago
  What did you try to do? 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
  - ceejayoz 14y ago
    Pain points we've run into: * 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.

joebeetee 14y ago

It's still broken for mobile web

joebeetee 14y ago
http://developers.facebook.com/bugs/ http://developers.facebook.com/bugs/ is broken as well if you are logged in. Big bug.

jhaile 14y ago

Does anyone know if there is a workaround if you are currently using the FB.login method to authenticate users?