The documentation mentions using FBInstant.player.getSignedPlayerInfoAsync() to get a signature when communicating with a custom backend.
https://developers.facebook.com/docs/games/instant-games/guides/bots-and-server-communication
Can I store the signature in a variable at the start of the app and then just use it throughout all the XMLHttpRequests for the current session?
Or do I need to call it everytime I make an XMLHttpRequest?
You are free to only call it once, however this will not allow you to validate the issued_at time, or to encrypt custom payloads.
Related
With there being rate limits should I ask for an increase when trying to get all access approval? Since my app asks the driver/ rider to sign in using their uber credentials will this help limit the calls to the API?
Thanks in advance.
Probably not, but it depends entirely on your purpose.
Calls to an API are usually done to get or update data on the home servers, in this case Uber's servers. As such, any Uber specific information you require will likely need to be accessed through their API.
Now, I've not reviewed Uber's API so if you can use the return from the login request to resolve all your needs then great. However, if you need to get data from their servers it would only reduce calls to the API if they require data returned on the login which can only otherwise be retrieved by making another call to their API.
Actually I have an API called update user data, it is called when the user moves from one page to another page. If the user copy the API from console and post in postman, user should not able to update the user data. How to provide security or implement feature to not to update data through post man.
You really can't.
You can slightly make it harder using some CSRF protection, but that's just it - it will only make it a bit harder, but not stop anyone determined.
If your API is public, you should be ready for your users to have custom client apps.
I am a bit confused by your question. Because PostMan or other applications like Fiddler are created to make the job easier for developers during development. anyhow if you are concern about who makes call to your webpage, you can make your API private and just give access to the user that have the right credentials. You can also read about CSRF or XSS.
I have been asked to use ember for front end and java rest services as the backend. I am trying to figure out how to manage session for a particular user.
i know there are couple of options like storing in the local store, cookie but they are error prone as some users might disable those features. I want to know what is the preferred approach in normal enterprise apps.
Mine app is simple 15 page app. i need to capture user, and some profile details.
Session are usually more of server side part. You have to just make sure whether the provided session is available or not for every transformed route and request. There is a library which takes care of authentication and authorization in ember https://github.com/simplabs/ember-simple-auth.
Currently as it stands, if a user reads the source of my web application, they'd be able to determine the direct URIs of all the RESTful services my web application utilizes.
The problem I see is this: My web application knows how to correctly use the API, and I might not have thought of every single validation known to man to prevent bad data from being sent through the API.
And so with that is there a method to prevent "direct" access to the API and limit it only to my web application?
P.S. As an FYI: API calls concerning a user are protected by the presence of a user-specific cookie which is only issued upon login. This means I'm not too afraid of User X being able to directly modify User Y's data through the API.
No.
If the browser is making the request, the user can spoof the request. Period.
My web application knows how to correctly use the API
That's good, but that's leading you down the path of assuming client-side functionality executed as intended. Never make that assumption.
I might not have thought of every single validation known to man to prevent bad data from being sent through the API
This statement leads me to believe that the API itself is more complex than it needs to be. The best thing you can do is simplify. It's difficult to be more specific without seeing specific code, but API requests should be fairly simple and straightforward and the same techniques to prevent malicious code from getting through should be applied universally. The same general rules apply here as in any web application interaction...
Never trust anything that came from the client
Never assume client-side code executed as intended
Never execute input as code, always treat it as a raw value
and so on...
As you mention toward the end, you've already taken care of authentication and authorization for the requests. Given that, if User X is permitted to make a given API call, then what you're essentially asking is, "How do I allow User X to make an API call without allowing User X to make an API call?" The server can't tell the difference. A request is a request.
Sure, there are things you can try, such as always including some custom header in requests made from code. But anybody can inspect that request and spoof that header. The user's browser isn't part of your application and isn't under your control.
I'm building an iOS app which will communicate with a set of .NET WebServices. I'm trying to find a way to ensure on the WS side that the calls being sent actually came from the iOS app.
There is, of course, a "login" method which requires a username/password combination. I would like to add a "security token" to this method, which I can use to validate that the request is coming from the iOS app.
Since this is a parameter to the login method, is must be something known by the app and the web service BEFORE a valid login occurs. Additionally, it should be something which is impossible (difficult?) for another application to fake.
Are their any best practices / standard methods for this sort of exchange? Am I even thinking about the problem in the correct way?
Thanks in advance!
Take a look at the oAuth specification (used by Twitter) it requires that a user is verified first, during the process a series of tokens are exchanged, and then the token is used to sign the data during subsequent data exchanges.
It works on the principals of public/private matched keys, so you have one key that is always kept a secret.