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.
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.
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.
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.
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.
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.
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.
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?
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.
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?
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?
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.
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).
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.
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.
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].
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.
49 comments
[ 3.5 ms ] story [ 37.4 ms ] threadEdit: nevermind, retried a few times and it's ok now
Works fine at https://connect.beta.facebook.com/en_US/all.js
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
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.
[1] http://www.datacenterknowledge.com/archives/2009/05/14/whos-...
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).
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.
...and figured we had some kind of virus outbreak hijacking DNS, but now connect is down and everything is fine. Hm... coincidence?
"Oops! Google Chrome could not find www.facebook.com"
https://developers.facebook.com/docs/authentication/client-s...
[0] http://www.stevesouders.com/blog/2011/10/13/frontend-spof-su... [1] http://www.stevesouders.com/blog/2012/03/28/frontend-spof-in...
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.