Facebook Connect down worldwide | Hacker News Reader

Facebook Connect down worldwide

developers.facebook.com

76 pointstantalor48 comments

Flagged. Pages submitted to HN should not be behind login walls.

This thread already has multiple references to the fact that you have to log in to see the submitted post. Some are justifying this by saying the content is only relevant for people/developers who have FB accounts. While this may be true, there are many HN users without a FB account. For them, this submission is nothing better than spam that attracts unverifiable comments.

Although there is a large intersection between the two groups of HN and FB users, you don't have to be signed up with any other webservice in order to use HN. This is not only about FB. As a matter of principle posts to HN should be accessible for all HN users without requiring them to sign up with any other webservice.

Der, does that mean online.wsj.com is banned as well?

Why on earth do I need to log in to read what seems to be a bug report?

Perhaps a better question is, why not? It affects Facebook users, so it makes sense to be one (and therefor have no issue with signing in) in order to view the bug, right? I don't see the big issue with that. It seems like "having to sign in" is a popular thing to dislike, lately - not just for Facebook.

What if I don't have a facebook account? I'm a software developer who would like to learn from other's mistakes.

Sometimes software developers have to do things they don't completely enjoy in order to do their work, like write PHP code, or test software, or fix bugs, or read documentation, or read other peoples code, or go to meetings, or create accounts on the system they're writing software for, or look at widely used systems that they would not normally use themselves. It's a hard life. But then again, there's an upside: you get to listen to yourself complain about having to do things you don't like doing. And that makes it all worth it.

Why do Facebook owe you that for free?

They asking people to prove their identity while it is completely unnecessary. If you ask me my id before even telling me what we are going to talk about, I will probably go away.

This is ridiculous. Who forces login to view, say, Bugzilla bugs? I don't know of any such project.

If you can't be bothered to sign in, why do you want to see a "bug report" that affects facebook users?

Yes, heaven forbid a site that consists of a bunch of software developers wants to read about why one of the largest sites in the world is having an issue.

Some people choose not to have a Facebook account on sheer principle.

Those people probably aren't developers of Facebook apps, though.

Such a bug report is of little consequence to those individuals.

That doesn't mean we don't want to know what happened or why.

Funny; we were getting some redirects to weird spam sites via: http://fwdservice.com/?dmn=connect.facebook.net\&gief=ye...

...and figured we had some kind of virus outbreak hijacking DNS, but now connect is down and everything is fine. Hm... coincidence?

Well that explains why I wasted half an hour trying to fix that today :)

Same here...

It would be nice if they have a status you could call before you use the login service, e.g. is_facebook_running: dologin; else sorry_facebook_down. I use several APIs that offer this.

you mean https://www.facebook.com/feeds/api_status.php ?

Won't that add a whole round trip before actually getting the content?

You don't have to call it on every request, just every 30 seconds or so and include the response with your script.

It's times like this that remind me how important it is not to completely rely on 3rd party scripts. Try pointing all 3rd party scripts to a non-existent server and see how long your website takes to load. This can be mitigated by loading scripts asynchronously.

If only Facebook thought of loading their SDK asynchronously. Oh wait, they did:

https://developers.facebook.com/docs/authentication/client-s...

Many sites load Facebook's script synchronously [0]. My point is that developers should be aware of this issue, not that Facebook have done anything wrong. For example, Twitter and Google Analytics are often included synchronously [1].

[0] http://www.stevesouders.com/blog/2011/10/13/frontend-spof-su... [1] http://www.stevesouders.com/blog/2012/03/28/frontend-spof-in...

That's just a static js file correct? When you get Facebook big, doesn't make financial sense to host static content on Amazon CloudFront, but it would avoid any downtime. I wonder what their CloudFront monthly bill would be, just to serve this one js file?

Facebook does exactly this. connect.facebook.net is a CNAME record to 'connect.facebook.net.edgekey.net' which is, of course, Akamai.

Akamai is essentially doing what you describe CloudFront handling, except at a much larger scale and with an existing wide deployment into Facebook's infrastructure (all of their photos/videos are served by Akamai CDN, for example).

Why do you believe hosting it on CloudFront would avoid any downtime? Everything fails eventually.

With Amazon's footprint and the number of datacenters around the world, it would be super unlikely that CloudFont would ever completely fail to serve content.

As of 2009, Facebook had 60k servers worldwide, while Amazon had 40k dedicated to EC2 [1]. While Amazon has a lot more going on than just EC2, doesn't this indicate Facebook's and Amazon's footprints are at least on approximately the same order of magnitude in terms of number of servers?

[1] http://www.datacenterknowledge.com/archives/2009/05/14/whos-...

You think that Facebook's hosting is somehow inferior to Amazon CloudFront? You do realize that Facebook is much bigger and probably has more datacenters than Amazon right?

Facebook, Amazon, Google, Yahoo, etc. all have plenty of redundancy built into everything they release. This is/was a fluke that could have affected any of them.

From 2010 http://www.facebook.com/note.php?note_id=409881258919

For what it's worth, FB has indicated to my company in the past that in situations like this one can refer to http://connect.beta.facebook.net/en_US/all.js

Out of curiosity, I decided to paste the code into jsbeautifier.org. Line 6 of the result:

    function bagofholding() {};

The only other references to it much further down in the file:

    if (!p.whenReady) p.whenReady = bagofholding;
    if (!p.onMessage) p.onMessage = bagofholding;

If you Google for "bagofholding" (without quotes), the second result is this wikipedia article [1]:

A bag of holding is a fictional magical item in the Dungeons & Dragons roleplaying game, capable of containing objects larger than its own size. Since its introduction, it has appeared in other roleplaying games and media.

[1] http://en.wikipedia.org/wiki/Bag_of_holding

bagofholding is also mentioned in this strange WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=62122

Also isn't https://... which gives a cert error in Chrome.

The certificate is for *.beta.facebook.com not .net

Works fine at https://connect.beta.facebook.com/en_US/all.js

Which doesn't seem to be loading for me.

Edit: nevermind, retried a few times and it's ok now

Does anyone know for how long it was down?

My site uses Facebook Connect exclusively and I noticed my stats for the past few hours are way down.

Wondering if it's due to the outage, or if I'm just having a slow day.

Sometime shortly before 8pm Pacific time to around 9:30pm Pacific Time.

Apparently facebook's top level domain is now having trouble too.

"Oops! Google Chrome could not find www.facebook.com"

And I've been looking where was the problem in my code for 30 minutes until I gave up and came here to read that...

Wonder if this is related to the launch of their new datacenter? Did the bugreport say?

Heh, I was just removing the Facebook share widget from our codebase and had left the reference to their JavaScript in. Just noticed it 404'ing and was happy as I would have accidentally left Facebook's javascript on our page unnecessarily otherwise.

Any reason why you're removing it from your entire site? Was it not worth it's kb in size?

We were trying to use it to allow users to share content without being taken from the site. We ran into numerous problems that I think stemmed from the click-jacking protection as well as it just being incredibly inflexible in a variety of ways. Further, it's friends (twitter and pinterest) more or less demand that users leave the current page. So we decided to go with the tasteful Zocial icons instead and trust that users will not be too distracted by the popup window.

Also, no haterade on the sharing thing. It's a charity project that is all about people "getting the word" out and the sharing is unobtrusive.

This cheered me up a little, I confess.

Reply on news.ycombinator.com