The company I work for has recently installed a Apache staging server which uses Apache's mod_access module to prevent unwanted access to our staging environment.
One of the downsides of this is that Facebook, when trying to scrape the page for the opengraph metatags, comes up empty with the following error.
Error Scraping Page Bad response code
Which is to be expected since the scraper bumps into the authentication dialog.
My question now: is there a specific IP range that we can allow access
to the website?
We've looked at allowing certain headers, but that seems a little prone to header manipulation in order to bypass the security layer.
The access log did show one IP address, but I assume that Facebook uses multiple servers to scrape all these pages and I seem to remember reading that these IP addresses tend to change over time.
Any ideas?
Facebook has published their IP range here.
Related
Note: Solved - question makes no sense, my understanding of CORS was incorrect and lead me to ask this question.
The answer is simple as pointed out by #CBroe below - CORS needs to be configured on the game server (in the example in this qestion).
I have a Facebook WebGL game that I'm wanting to host using Facebook's simple hosting (https://developers.facebook.com/docs/games/services/contenthosting/).
Is it possible to use Facebook's Simple Hosting for a WebGL game and still contact my web server (mygamedomain.com)? Is there somewhere in the FB app config to specify domains to allow?
Is the only way to get around this to serve the game from mygamedomain.com also?
I'd really like to avoid serving the game from my webserver if possible.
Any ideas or suggestions?
Not doing so will generate an error as expected:
XMLHttpRequest cannot load https://mygamedomin.com/mygame.php. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://apps-1287636812638.apps.fbsbx.com' is therefore not allowed access.
Just to be clear as there seems to be some confusion:
Game is hosted by facebook using their "Simple Hosting" service, not on my own server, .
I know CORS is the solution - the question is - does Facebook allow/support this? If so where do I configure the domains to allow.
If this was on my own server I the answer is trivial - CORS. But it's not.
There are hacks to circumvent cross-origin restrictions - I'm not looking for these. There's plenty of resources already covering these.
Edit: changed the title to more accurately reflect my question.
CORS is the solution to your problem here.
This question/the answer is not Facebook specific - the issue would be the same with any other domain serving your content, that is different from your own.
Your client-side code is hosted under the Facebook domain, and tries to make a request to your domain - that is the cross-domain part. Your domain is the party that holds the power to either allow or deny this request - by default, it would be denied, but by responding with the appropriate header, your server can signal to the browser, "yes, that's ok, he [your code running under facebook.com] is one of the good guys ..."
So you need to configure this on your server, that you want to make the request to.
I'm in a conundrum, and could really use some help...
I'm having difficulty trying to find information regarding how to enable a site -that already has X-FRAME-OPTIONS: SAMEORIGIN encoded- to be loaded into an iframe from a couple of specific domains (i.e. domain.com would be the common TLD). The issue is, that although this would be quite simple to do -using X-FRAME-OPTIONS: ALLOW-FROM http://domain.com-, if that were the only domain which would ever have a need to access the target site via an iframe. In reality however, I actually need to figure out how to set it up for (currently) three sub-domains -with the possibility of allowing from even more in the future- of the original TLD (i.e. example1.domain.com, example2.domain.com, and example3.domain.com), to be able to access the site while loaded inside the intended iframe. The only info I've been able to find regarding this issue so far is quite a bit outdated, and says that there is NO POSSIBLE WAY to allow a wildcard reference (or any other form of multiple domain reference) for a particular domain that would also apply to it's subsequent sub-domains (or anything along those lines) that seems to be effective at both functioning as intended and also preventing 'Clickjackin' by malicious individuals from occurring. I was hoping that someone more knowledgeable (and better versed in X-FRAME-OPTIONS) than myself might actually be able to offer me a feasible resolution.
Thanks in advance.
If you can entertain approaches outside of X-Frame-Options, consider creating a server-to-server API that can be called to access the content in question, and then allow it to be displayed without requiring framing.
That is, instead of ClientSite containing an IFRAME referencing the FramedPage which does the page assembly within the web browser, ClientSite calls an API on the backend to get the content directly from you and inserts the content into the page on the server before delivering the page to the user's web browser.
This gives you substantial flexibility. You could require an API key, apply basic server-to-server IP address whitelisting, or whatever suits, to prevent unwanted callers of your API.
It seems like this would be really, really easy - but I can't get it to work. All I need to do is to be able to serve files from Google cloud storage while restricting access to my google apps domain. I easily did this before using Google App engine simply by choosing that I wanted to limit access to my domain and setting the app.yaml appropriately. I can't find anything that tells me what I might be missing - I've tried using gsutil to set the ACL to restrict to my domain, which processes successfully through the command line, but then when I try to look at the bucket or object permissions through the cloud web console, I get "unexpected ACL entity type: domain".
I'm trying to access using storage.googleapis.com/bucket/object (of course with my bucket and object name) and I always get a 403 error even though I'm definitely logged in to gmail, and as the administrator of the domain, it seems like it should work because even if the ACL's were otherwise wrong (and I've tried it both with and without the domain restriction), and that it would work for me at least. The only way I can serve content using the above url is if I make it public - which obviously is NOT what I want to do.
I'm sure I'm missing something completely stupid, or some fundamental principles about how this should work - can anyone give me any ideas?
I'm not 100% sure what your use case is, but I'm guessing that your users are attempting to access the objects directly from a web browser. storage.cloud.google.com accepts Google authorization cookies, which means that if a user is logged in to an appropriate Google account, they can access resources restricted to certain users, groups, or domains. However, the other endpoints do not accept cookies as authorization, and so this use case won't work.
These users have permission to access objects using storage.googleapis.com, but doing so requires explicitly authorizing requests.
In othe words, a simple <img src="http://storage.cloud.google.com/bucket/object" /> link will work fine for signed-in users, but using storage.googleapis.com requires explicitly authorizing requests with via OAuth 2.
I am using Facebook Graph API. To set it up, I need to fill out the App Setting on developer.facebook.com.
I need to specify two URLs, one for local testing (localhost:3000), and another for live app. How should I do this?
Thank you.
I need to specify two URLs, one for local testing (localhost:3000), and another for live app. How should I do this?
That’s not possible – at least not if you want to use Facebook login.
You have two options:
Set up a second app for testing. This works quite well, as long as it does not come to things like Open Graph actions which need to be approved by FB and are tied to the app they were are proved for.
Set your local test environment up to be accessible from your local computer by the domain name used for the live site. F.e. when using Apache as webserver, by setting up a corresponding VirtualHost and manipulate your local DNS into resolving the domain to your local IP (via hosts file under windows). Also since your live app will most likely use port :80, you should set up your local server to answer to HTTP requests on that port.
I'm developing an intranet-based web app that integrates with Facebook via the Graph API. I am struggling to get OAuth working, and I think it's because I'm using an IP address rather than a domain.
I've registered three apps with Facebook, one for dev, one for staging and one for live. They are all configured identically, and for each one I've specified the Site URL in the Developer portal accordingly (I've masked some parts - they're real numbers in Facebook):
Dev - http://localhost:XXXX/
Staging - https://192.168.XXX.XXX:XXXX/
The URLs for the OAuth dialog output as you would expect - only the App ID and redirect URL are different on the three systems:
http://www.facebook.com/dialog/oauth/?response_type=code&display=popup&scope=create_event,publish_actions,publish_stream,read_stream,offline_access,manage_pages,read_insights&client_id=XXXXXXXXXXXXXXXX&redirect_uri=http://localhost:XXXX/path/to/redirect
The dev version works fine but staging and live do not - I just get
"An error occurred. Please try later".
Am I right in thinking that Facebook's OAuth doesn't accept using an IP address rather than a domain for Site URL, and if so is there a way around this?
You are correct, you cannot use IP addresses. You can use domains or even subdomains, but IP addresses won't work.