
Facebook breaks logins - apoorvamehta
https://developers.facebook.com/bugs/207955409343730
======
Smerity
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-...](http://techcrunch.com/2011/08/11/facebook-wins-worst-api-in-developer-
survey/)

~~~
chii
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
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.

~~~
dsl
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
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?

~~~
dsl
_shrug_ maybe all my developer friends are wrong. I don't bother with FB API.

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.

------
bleonard
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

~~~
hayksaakian
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?......> 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.

------
supervillain
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.

~~~
akx
Facebook stores three hashes of your password (let's say it's "pAssword"):

* "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.

~~~
bungle
I don't think they store three hashes, but just try to validate password with
three hashes.

Something inline this:
[https://github.com/bungle/web.php/blob/master/password.php#L...](https://github.com/bungle/web.php/blob/master/password.php#L50)

~~~
sehe
What's the password doing on their server?

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

~~~
bungle
You seemingly don't understand a bit about it. And you seemingly doesn't
understand how crypt works. Let me educate you:

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

------
alex_c
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
I'd go with Instagram's over Facebook's.

~~~
phillmv
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
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.

------
aidos
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
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.

------
thathoo
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>, :authorize_url =>
'<https://www.facebook.com/dialog/oauth>, :token_url =>
'/oauth/access_token'}}

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

------
joebeetee
It's still broken for mobile web

~~~
joebeetee
<http://developers.facebook.com/bugs/> is broken as well if you are logged in.
Big bug.

------
edouard1234567
seems fixed.

------
sutro
Is the United Breaks Guitars guy available?

------
contingencies
<http://imgur.com/V5LD0EB>

