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.
Related
I am writing a REST API using Express Js and I have some questions regarding security.
My first question is what information can hackers get from a request made from the client side. Can they figure out the request link? What about the body and headers? Is body more secure than parameters/vice versa?
My second question is if I implemented a CORS whitelist that only allowed origins that I wanted to access my API, would that prevent anyone else from hitting the API endpoints? Can people find ways around CORS?
When a REST api is called from a browser client, everything should be treated as completely open. Anyone can read urls, headers, bodies, etc. There is no reasonable way around this, and you should design your system with this in mind.
CORS does not prevent someone from writing a script to call your API either. CORS does not add security, it takes it away by making it possible to call your API from browser applications on other domains. Not having CORS technically makes it harder to call your API in some contexts, and removes a potential security concern. The S in CORS stands for 'sharing', not 'security'.
Any security you need should be based on the server. For example, if you have data in your API that can only be read 1 user, then the server needs to make sure that a different user cannot read it. To do this, a user needs to authenticate itself.
I am using this link for example to load the link. Although the link is a http link it will be redirected to a https link. It works in the browser.
However, as soon as I let my iOS Application load the resource it will say "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection.".
I am using this library to load the picture. Is it not supported that Swift loads the https resource? I could think of that ATS blocks the connection to the server so the redirect can't even be received.
I would be very thankful for any thoughts on this.
Christian
While you certainly can disable the entirety of ATS using the solutions provided by Kishan and Johnson, if you know the domain of the http resource you are trying to load, you have better options. For details of why the disabling of ATS entirely is not the best idea, see this post.
Better options are:
If you know the http resource is always going to give you a redirect to the same https:// url, why not simply use the https:// url in your code. This won't work if the redirect is dynamic, but if your code is trying to load http://www.example.com/resource and that always redirects to https://www.example.com/resource, why not just change your code to go to the https version.
Only disable ATS for the domain in where you need to allow non https connections. This allows you to only allow http connections for domains you know don't support https, better protecting your application users.
Your ATS settings in your info.plist wqould look something like this:
If and only if your urls are driven by data that you don't control (i.e. the domains in those urls could be anything), you will need to disable all of ATS, and Apple may eventually want you to provide justification for disabling it. Originally they were going to have all ATS disabled apps go through an additional justification request processs, but they haven't mentioned that recently. This should be a last resort.
Honestly, looking at your example UR
Go to info.plist add a term called App Transport Security Settings.
And under that add Allow Arbitrary Loads
I am currently implementing a Facebook Chat Extension which basically is just a web page displayed in a browser provided by the Facebook Messenger app. This web page communicates with a corporate backend over a REST API (implemented with Python/Flask). Communication is done via HTTPS.
My question: How to secure the communication the Web page and the backend in the sense that the backend cannot be accessed by any clients that we do not control?
I am new to the topic, and would like to avoid making beginners' mistakes or add too complicated protocols to our tech stack.
Short answer: You cant. Everything can be faked by i.e. curl and some scripting.
Slightly longer:
You can make it harder. Non browser clients have to implement everything you do to authenticate your app (like client side certificates and Signet requests) forcing them to reverse engineer every obfuscation you do.
The low hanging fruit is to use CORS and set the Access Allow Origin Header to your domain. Browsers will respect your setting and wont allow requests to your api (they do an options request to determine that.)
But then again a non official client could just use a proxy.
You can't be 100% sure that the given header data from the client is true. It's more about honesty and less about security. ("It's a feature - not a bug.")
Rather think about what could happen if someone uses your API in a malicious way (DDoS or data leak)? And how would he use it? There are probably patterns to recognize an attacker (like an unusual amount of requests).
After you analyzed this situation, you can find more information here about the right approach to secure your API: https://www.incapsula.com/blog/best-practices-for-securing-your-api.html
I have implemented an authorized action as explained in this question as well as the answer by #vdebergue.
This was working great, and the requests made by the front-end application were automatically adding an X-XSRF-TOKEN request header, with the token obtained from the login response.
However upon deploying both front-end and back-end, the requests issued from the browser are no longer adding the X-XSRF-TOKEN request header, thus causing an Unauthorized response from the server (rightfully so).
What I am failing to understand is, what is it that changed between development and deployment?
I do have the request header specified in cors.allowedHttpHeaders:
play.filters.cors.allowedHttpHeaders = ["Accept", "Origin", "Content-Type", "X-XSRF-TOKEN"]
I doubt I have to add this header manually from React (in fact the issue probably has nothing to do with the front-end).
Thanks!
Edit 1:
List of XHR requests:
Details of the login POST request, can see the X-XSRF cookie and the token being passed:
Details of the unauthorized GET that is not setting the X-XSRF as request header:
Same as previous screenshot, but running on localhost, getting authorized with the header added:
Assuming you implemented correctly, and the cookie is not attached during deployment, the issue might be related to the domain of your cookie. The way I did it is to define an an env variable and use it to hold the domain value; so it does not break the implementation during development and tests.
You can look at the Playframework API documentation for more information on how to use the cookie.
Solved in an unconventional matter: front end was made with react, which offers a way to build a static production version.
I simply integrated those static files with play framework's index.scala.html, instead of trying to run it as a separate app on a different port.
It works, however i will not mark it as a best answer yet, because i don't know whether a mobile app connecting to the same play framework backend will play along nicely when it comes to authorisation and cookies. Mobile apps are not browsers (and maybe don't abide by their limitations), and Postman had no issues with cookies.
To be checked.
I want to create and test an app initially from localhost (were I run Ruby on Rails or Glassfish). I have read many postings about how to do this and NONE work. I have tried all the solutions discussed on stackoverflow and other sites.
Does anyone have a current method that does work (2015)?
Following did not work
1) in Canvas URL http://localhost:3000/users/index/ with and without localhost as domains
2) Tried editing the Advanced tab to add redirect URL to same URL.
What happens is I get a blank screen (I have even tried really simple hello world type apps that run locally so it should work with facebook).
Thank you,
Lynne
you have to configure secure canvas URL for canvas apps . it is mandatory and it has to be a https URL.
edit: This is actually a lot easier than I thought. I found this python script that creates a local https server. The only issue was that facebook is sending a POST request on the canvas page, and this server doesn't support POST requests, so I modified it a bit and now it handles the facebook canvas page correctly.
You don't need a domain, and in the script it tells you how to generate the self signed certificate. In the facebook app settings you can set https://localhost:4443/ as canvas url.
old post:
It is possible but it's a bit of a hassle. You can set a dns to 127.0.0.1 and use that. So if you own example.com, you can create an A DNS record for localhost.example.com and set it to 127.0.0.1.
The difficult part is that you have to find some way to create a certificate for this domain. If you want an official cert, the easiest option out there is Let's Encrypt. Verification of your domain through an https server is going to be difficult, since the Let's Encrypt servers will try to contact 127.0.0.1. So you're probably better of using DNS challenge validation. Another option would be a self signed certificate, which is a whole different story.
The last step is to find a server that can host https and use the certificates you generated.