I'm using Teamwork as a project management tool in my team. It is a great tool, but it ridiculously lacks some important functionality. For example, their reporting facility sucks.
Though, they have API using which I can build reports myself. API key is specific to the user, so using any given API key you get access of the owner of the key.
So, if I give my API key, anyones who has it, gets access to all infromation in Teamwork (including information under NDA). So giving my API is not an option.
Making an app where I need to put my API key manually is not an option too, as developer still can get access to this key (by simply recording all inputted keys).
So my question is: is there some way to make authorisation like the one facebook has for other sites for services where such kind of authorisation is not implemented?
Related
I am creating a connection between a clients Shopify store and an order management system called Extenda NYCE. For this I have created a custom app and given it all necessary accesses via the Admin API congifurator.
When I've configured the app and installed it in Shopify backend I use the API keys to get access to it via the order management system, but I get an error. Due to poor UX I can't see the whole error message but basically what I am doing is I try to make an article import by using the API keys.
Now I've tried to find a solution to this by reading about using API keys and I seem always to end up in information regarding access tokens and the need of implementing access to these so that the third-party system can get access to the API.
I'm totally lost so I figured why not look it up with StackOverflow. Have you had similar experiences? To me it just seems way too advanced if I need to write scripts to generate access tokens so that the API can have access to the shop data. Isn't the API interface developed NOT to have the need of writing code in Shopify?
I've been creating an extension for VSTS, and so far i have stored some data in documents in collections (https://learn.microsoft.com/en-us/vsts/extend/develop/data-storage).
The problem I have now, is that I need to GET these documents somehow from an external application. I have looked into: https://github.com/Microsoft/vsts-auth-samples/tree/master/ClientLibraryConsoleAppSample to get the authorization done, but then I am unable to get the documents. If I try to access through the REST API I have issues authorizing myself(without the personal access token provided. The application is supposed to work for every user, and i cannot get and use every user's personal access token. This is not feasible for 350+ people) as well as I am unable to get the REST API working. The documentation on all of this is severely lacking.
Anyone able to help?
The documentation is lacking, because the Data Storage is isolated for the extension and there is no easy way to access the data from outside of the extension. If you need external access, you also need to store your data externally. Azure storage or in a TFVC/Git repo under the VSTS account.
As for per-user storage access, that's also isolated and would indeed require either a account owner token or a user specific Oauth or PAT token.
I have found the solution. The documentation states that there are 2 ways of working with the documents/collections. REST API and their VSS wrappers. The url required to get all documents in a certain collection is as follows:
https://{account}.extmgmt.visualstudio.com/_apis/ExtensionManagement/InstalledExtensions/{publisherName}/{extensionName}/Data/Scopes/Default/Current/Collections/{collectionName}/Documents/{documentName}.
Using this in a browser works just fine. All that needs to be done in order to use this with an external application is authorization.
If you use sdk methods from docs like VSS.getService(VSS.ServiceIds.ExtensionData) you can view (easiest in dev tool in browser) the request.
Its look like:
https://extmgmt.dev.azure.com/{organization}/_apis/ExtensionManagement/InstalledExtensions/{publisher id}/{extension id}/Data/Scopes/Default/Current/Collections/{collections (by default 'MyCollection')}/Documents
Suppose I have a working REST API for my product.
I want to give access only to developers who sign up to this product. Also, there will be several plans available so certain parts of the API are not accessible on the free plan.
From the grant types I've seen only the client-credentials one seems to be the closest solution. However that won't authenticate the developer account stored in my product db, it will only get an access token for that client. The user won't actually be 'logged in' per se. Add to that the fact that a single client can be reused by everyone, according to implementations I've seen.
The only way I see is creating a custom grant type, by adding an extra api_key to the client credentials type, which pertains to the developer account.
Is there a way to do this with the existing grant types? Introducing custom types will not work with many oAuth2 libraries out there out of the box and I don't want to give the developers the hassle of modifying them.
I don't think you have to invent a custom grant type.
A single client can be reused by everyone only if everyone knows the client secret.
So, it seems that what you have to do is (1) to authenticate a developer when you issue a pair of client ID and client secret to the developer and (2) to motivate the developer not to reveal the client secret to others.
The reason for using an API key has been mentioned in this post(What is an API key?) like this :
"Typically, if you can identify the source of a request positively, it
acts as a form of authentication, which can lead to access control.
For example, you can restrict access to certain API actions based on
who's performing the request. For companies which make money from
selling such services, it's also a way of tracking who's using the
thing for billing purposes. Further still, by blocking a key, you can
partially prevent abuse in the case of too-high request volumes."
The above answer is relevant in case of commercial services but what about services like google recaptcha which is a free service? What is the point in having an API key in this case and why do they provide a public and private key?
Valid point. I wish the answer was so that you can see analytics for each of your sites and how many captchas are being displayed, attempted, passed, failed, etc. This would be meaningful information for the website admin. However, I don't believe Google currently provides that information for recaptcha. In this case, I think the answer is so that Google can track that information for their own use, and the reason for the private key might be so people attempting to test programs that break recaptcha must use their own key, making it easier for Google to detect and isolate it, and therefore take measures to change recaptcha to prevent exactly those types of cracks.
We have a large high traffic site with a lot of data on it (similar to Kickstarter), and we want to provide to our content/project creators a means of pulling their data from our site via an API.
Someone suggested I use OAuth, however my experience with OAuth is limited to setting up a twitter datasource.
What I want to do
Provide a user an Application ID and a 'secret'
Allow this user to connect to our application via an api endpoint, authorizing themselves using the api ID and secret
Once verified, allow this user to pull only their data from the application
The data that a user can pull: votes they have cast, pledges they have made, purchases they have made, projects/ideas they have launched, data about those projects/ideas (votes/purchases/orders/cancellations etc)
My question is:
Is OAuth overkill?
Is there a better way to handle a user/users website to connect to our API and pull/verify certain data by using the API we make available, while requiring each incoming request to be authorized for the user/site initiating that request.
Ideally, we will have an endpoint that is accessed as:
https://api.oursite.com/request/params
We want this to be as simple as possible for our users that wish to implement this interface. Thanks for your help!
Generally it's OAuth, in combination with SSL. That's the standard and is likely to stay. Before we saw also logins: username + password to access an API but that's becoming less and less.
So the suggested way is OAuth. There are no serious other solutions yet. To make it easier to adopt your API you could release some classes in some development languages so developers can have a quick start. You could start releasing those classes at for example GitHub to raise adoption of your API and get a quick access to developers. They might, if you do well, even start improving it.