I'm trying to design a good RESTful API for my web app and am looking at Facebook's Graph API as an example.
My plan is to dogfood the API in the web app. For example, if the user changes their name, gender, etc., on the settings page, it would just PUT to the /user endpoint of my web app with the new data.
However, I noticed that Facebook's Graph API does not allow modifications to the User resource. Are there some resources that you want to make sure are not modifiable from the public API?
I'm basically just wondering if there are any risks with my method, and if not, why other websites don't do the same thing.
Yes, there are resources that you want to prevent API users from modifying, but they are application dependent. For instance, an API I'm working on right now lets callers read but not update audit data, read user records (but only modify parts of their own), and create and update home addresses.
You will want to make sure that you have rigorous security in place to prevent users from modifying certain parts of a User (such as username or password), especially if user A is calling PUT /users/B.
Related
I have a backend app that provides measurement data through the use of REST API.
Now, I'm creating a frontend app that can visualize and query that data depending on parameters such as city, fromDateTime, tillDateTime, sponsorId etc.
I'd like to assign attributes to specific users that would describe how visualization should look like and what exactly they can query from my REST API. For example, a specific sponsor of measurement devices can only see data from the devices they bought.
However, I'd like them to be able to make their data public. How to do that?
I thought, in that kind of situation, I could make a new user with appropriate attributes and make its credentials public. Then, create a URL with something like /user/{username}/data/ in the path. The username could be randomly generated and the password could be the same to all public users and could be hardcoded into the frontend app.
What do you think about this approach? Is it a good idea? Is it secure? Maybe there's another better way to do that?
Sounds like part of your application is only available to authenticated users and part of it to unauthenticated (public) users.
You are already using Cognito for the authenticated users. Sounds like you've done the hard part of locking that data down to the right users. The question is, why would you involve Cognito at all for your unauthenticated users? Sounds like the right answer would be to put the public data in a location that is publicly accessible in your application.
EDIT: I would not use Cognito to store application data. Whilst your data may relate to a user, it doesn't sound like authentication and authorisation data. More importantly, if you are accessing this data frequently for application purposes, Cognito is not scalable in the same way as something like DynamoDB. If you are still in design phase, I think perhaps you should look at putting this data into a database instead of Cognito.
I would like to access other users public data to show in my website when they configure the page by their username/id.
It means I will create an app on FB/Instagram side and with the help of this app's access token I would like to fetch public data of other user.
Is this scenario valid now? Earlier it was possible but I am not sure now with changes in policies. Even the documents are not clear enough which can say it's possible or not?
Has anyone tried this out recently?
Users: Only data of users who specifically authorized your App is available, depending on the authorized permissions. It does not matter if data of user profiles is public or not, you have to get permission from each user separately.
Pages: If you want to get data of pages you don´t own, you have to go through a review process with your App to get access to "Page Public Content": https://developers.facebook.com/docs/apps/review/feature/#reference-PAGES_ACCESS
That´s for Facebook, about Instagram you can just hit the docs (as well): https://developers.facebook.com/docs/instagram-api/business-discovery
My number one recommendation, in this case, is Facebook API or Instagram API from Data365. I may be considered biased since it is the tool I work for, but it is really a reliable tool you can get public profile data by users ID or username.
Of course, you can use the official Facebook/Instagram APIs for searching all public objects (post, user, page, event, group, place, check-in). But note, the official API has a number of restrictions. Andyrandy has already described them in his answer. Compared with official APIs, we do not have such restrictions.
Besides, our APIs provide such unique features as gender and age recognition (via face photos) along with identification of post reactions that give a competitive advantage in obtained analytics. Data365 APIs also enable developers to create monitoring tasks for a one-time or auto data update. And above all, we do not break the law but only provide web scraping within the legal framework.
I have two different objects in my API, we can call them users as tasks. I want to shape the API so users can only access tasks associated with them, but admin can access all tasks. How would I check to make sure what they are requesting matches their username? I have login working as per http://code.tutsplus.com/tutorials/building-rest-apis-using-eve--cms-22961 but I'd like to be able to create a more encompassing API.
You might resort to User Restricted Resource Access
When this feature is enabled, each stored document is associated with the account that created it. This allows the API to transparently serve only account-created documents on all kinds of requests: read, edit, delete and of course create. User authentication needs to be enabled for this to work properly.
See the relevant documentation at the link above.
Is it possible to ban users from using a Facebook application?
I'm not talking about the canvas or the discussions board (which is what I've found by looking around), but the application itself, that is, causing errors or preventing actions whenever the user tries to use the Graph API (in my specific case, an Android app that uses the Graph API to provide some features).
The scenario I'm envisaging is something like this:
user authenticates app to use its features and gets the access_token;
user uses the Graph API according to the app permissions;
user someday does something he shouldn't;
user is banned and, even if the access_token is still valid, Graph API requests fail, and will always fail even when deauthorizing and authorizing the app again.
Is this possible using the Graph API or the developers app console on Facebook, right now, or is there really no way to prevent users from misusing your application? I guess I may do something "out of band" to enforce this somehow, but being able to do it at the Facebook level as well would be much more effective and harder to circumvent.
See https://developers.facebook.com/docs/reference/api/application/
Use the 'banned' connection of the Application object to ban specific users from your App - you'll need the App access token to do this
Just create a blacklist of specific Facebook User IDs, and check the user's ID against the blacklist when they log into your app.
If the blacklist matches, show a message telling them that they are banned and don't allow access to any functionality.
I am new to this but I will try my best to explain what I am trying to do.
I have a catalog of products and various private information that my users want to be able to access via their website.
For example:
User-a has an e-commerce site and they want to sell my merchandise. They will be able to access a certain products details via a web service. They will also be able to see the negotiated rate that I've given them along with some other private details.
How should the API handle authenticating the request that comes from User-a's website?
I've been reading all day about different authentication methods but they all seem to revolve around the idea of a third party accessing specific user information. An example is if you let http://randomtwitterapp.com access your twitter profile. In that case, the third party site must manage multiple different users and auth tokens. In our case, my users website is interacting on behalf of the user. I hope this makes sense.
Let's call user A "Alice" because calling her User-A is cumbersome.
Treat Alice's web site as if it were Alice herself. The special pricing and such IS specific to the web site in question, so have it log into your site. Issue credentials that the person developing that site would use to authenticate with, and then use those credentials to determine the pricing and products you show.
As for actual authentication mechanisms, it really depends on your needs. If all you need to do is serve different data to different people, you could do something as simple as an API token passed in the query string: http://api.example.com/products?key=9af4d8381781baccb0f915e554f8798d
Or if Alice already has a username and password for your site, you could have her use those in her API requests with Basic Auth.
If Alice is going to need to enter her account information on various sites that she doesn't control, then oAuth comes in very handy. With that, you can essentially give her an API key for every site she needs to access your API from. And you give her the ability to delete those API keys and deny those sites access.