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.
Related
I have a flask website.
i would like the user to be able to schedule repeated requests for data from one of their Google accounts (let's say Gmail).
From within the website, the user would first authorize the application to access their private Gmail data. From then on, the application, would retrieve the user's Gmail data on a re-occurring basis, without needing to get authorization each time.
Is this possible? I know it would require a service account but can anyone point me in the direction of documentation that describes how this particular scenario might work.
Would such a scenario be allowed to persist long term? Or will their come a time when Google will require the user to reauthorize the application?
Correction, you should not use App Passwords. OAuth is the correct way to do it I believe:
https://www.oauth.com/oauth2-servers/signing-in-with-google/
Here's Google's docs on it, which is more specific to your need:
https://developers.google.com/identity/protocols/oauth2
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'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.
I'm writing a Facebook canvas webapp that performs a login (using urllib) to a third party website and performs actions on behalf of the user. This means I have 2 accounts; the account the user has with my webapp (via facebook) and the account the app uses to perform a login on their behalf (with user/password details provided by the user).
I obviously don't want plaintext passwords in the DB. But I also don't want the user to have to enter their password every time they perform an action. I want them to enter the password once when they sign up, and I want to encrypt the passwords, but what do I encrypt against?
Any key on the server would be available to anyone who had gained access (i.e. useless), so I was thinking of encrypting it against a value available via the Facebook API.
When the user logs in (and gives the app their access token), the app can request the value via the API and encrypt/decrypt their 3rd party password with this. Anyone with access to the server wouldn't be able to make this request without the user being logged in to the app. (This still means someone snooping on the server could get logged-in users 3rd party password, but anyone who got one-off access to the DB couldn't see passwords.) Is this wishful thinking?
You might as well encrypt it using a key on the server. If anyone gains access to your server they will have everything they need to retrieve the key even if you're getting it from Facebook.
I think the best you can do is to store the key in a location that isn't available to your webserver, but that is available to your script. At least make sure you don't store the key in the database.
Whatever you do beyond that would just be security through obscurity. The key here is to keep your server secure so that no one gains access to it.
I guess you could store the logins ONLY on the client, in some sort of local storage and do all the actions related to the third party, from the client in JS.
This of course would need some change in the architecture of your app if you tought to do all this from your server, but that would possible for sure, you can event make client JS send data to your server after it worked so you can log data from the interactions with the 3rd party.
Furthermore it has the advantage of distributing the load on the clients
I know you didn't tag the question with javascript and you seem to want a server pure solution, but It seems the best solution to me. the user keeps its data ..
Security through obscurity might be your best bet. Perhaps implement an algorithm to generate the key using something standard (like the current datetime). You can store the date in your db, and use that to generate the key using your own algorithm.
I am pulling list of docs in coldfusion via google docs API. I want users to click on the link and get signed in automatically in google docs, with my username and password. Google should not ask user name and password from them.
I tried out this example http://cfgoogle.riaforge.org/
Till now I am able to pull up list of documents I have on my google docs account.
But I want anyone to click those link and get automatically signed in as me. And able to access my documents. Is it possible?
I would guess that accessing the documents as you is not possible via the end-user's browser. Google will set a cookie on your computer identifying your session. This allows you access to documents, mail, etc. whatever is linked in your account. For them to be able to access the documents using your account, they would have to be logged in as you. You can't do that directly from your application, because you can only write cookies for your domain (oversimplification, but basically....)
There may, however, be a workaround.
One option would be to use the API to automatically share the document with the user. That is, they provide their Google ID (not password) and you share with their account. This is probably what I would try.
Alternately, you could proxy requests for documents, although this opens up a whole 'nother can of worms.