Is it possible to create "public developer app" for Dropbox (Business Api)?
I created a Dropbox account for "MyOrganisation" and I set up a Developer App (MyOrgApp) and retrieved appId and appkey. This App is using Oath endpoints to get the access token. When I login with MyOrganisaiton admin account credentials, I get the accesstoken which I can use to do Api calls for MyOrganisation. It works fine.
My question is that will I be able to use this App (MyOrgApp) to do Api calls for another organisation "Organisation2"? Or Dropbox apps are more like Private Apps where each Organisation needs to have their own app to make api calls?
The Dropbox Business API doesn't make a distinction between "public" and "private" API apps exactly. You can use your registered Dropbox Business API app to operate on multiple different teams, but you first need to get "production" access. You can find more information about that here:
https://www.dropbox.com/developers/documentation/http/teams#production
Related
I have been reading google+ API and domain API and found out that google+ API are read-only. And domain API is only for domain users. But somehow I just tried buffer, connected my google+ profile and shared some text. It appeared in the posts section. Now my profile was not a part of a domain, it was username#gmail.com. Also, there are other social products which give the same functionality.
How do this work?
Your app can share post on the behalf of the user on Google plus. All you need to do is take the appropriate permission from the user.
https://www.googleapis.com/auth/plus.stream.write Required - Grants
permission for the app to create posts or comments on behalf of a
user. The Google+ Domains API only allows creation of restricted
posts, and only allows comments to be added to restricted posts.
Ref : https://developers.google.com/+/domains/posts/creating
There is an open authentication specification called oAuth that utilizes public api's, for instance: GitHub. Facebook, LinkedIn, Twitter, Google, Slack, etc. I believe the easiest way to implement this strategy is either with a bot, webhook, or my choice api framework Express.
Express has a middleware library called Passport that enables a quick setup of the necessary steps to implement the correct api keys, secrets and callbacks. Essentially what you have to do is create an app with each provider and they will give you the api information necessary for your Passport configuration.
Once you've got that done, then you just hook up a simple router and server, then you've got an app that can allow your users to sign into whichever provider they choose. The beauty behind the solution is their password information is serialized inside a JSON store to prevent security issues.
https://developers.google.com/+/web/api/rest/
I got a dropbox-link with some files, protected by password.
I got the link, the password, dropbox business account, and App key, App secret that i got from creating a new App in https://www.dropbox.com/developers/
What is the next step?
Thanks
If you want to download a file from a Dropbox shared link programmatically, you can use the /2/sharing/get_shared_link_file endpoint. (That's the HTTPS endpoint itself, but if you're using one of the official Dropbox API v2 SDKs, there will be a corresponding method.)
This endpoint is accessible via Dropbox API apps, as well "Team member file access" Dropbox Business API apps, via the "Member file access" feature. Other Dropbox Business API apps cannot call this endpoint.
I get it that Oauth is used to grant permission to a third party application to access a user's data (like photos on his facebook account) without revelaing his facebook credentials to the third party application. For example, when you try to use an online photo editing tool and you want to load a photo from facebook, facebook will pop up a message asking whether you really want to allow the application to access your data. So at that point facebook just returns a temporary access token and the app can use it to access your facebook photos. (as i understand the scope for this access token is such that it only has permission to access the particular user's photos only) Yes, this sort of a setup is required because you can't trust a third party application that much as to give away your credentials.
Assume somehow instead of oauth, facebook used api key authentication. This would mean that all third party applications that have subscribed for facebook API already have a key which they can use to access facebook's data sources.So that the app can directly take you to your facebook photos and facebook will not notify you that an outsider is trying to access your private data. This approach is not suitable for an api that exposes user sensitive data but for apis that expose not so user specific (like google maps) data, the api key approach should be enough, right ?
So my question is, what are the criterion to decide which authentication type should be used ? And appreciate feedback if my understanding is wrong.
Here are 2 of the standard 4 Oauth2 flows which cater for the scenarios you mention.
Authorisation Code
Client Credentials.
Using your Facebook example above you could think of like this:
Use Authorisation Code flow for your "Oauth" scenario, where your app needs delegated authorisation to access a user's Facebook photos. This means the user must login and grant access to your app and your app must have an API key (client ID) issued by Facebook.
Use the client credentials flow for your "API Key" scenario. This would be when your app needs access to, for example, public Facebook pages / info and thus does not require specific user consent and can just use its API Key (Client Id & Client Secret)
After looking through multiple tutorials and posts, I have not found an answer or guide as to how to handle the following issue:
There is an Azure API App communicating with an Azure DocumentDB
There will be an Azure Web App (and some day mobile apps) communicating with the API App.
I would like for anonymous users to have access to read only information through the Web App (and only through the Web App). The
API App will serve up documents as requested. Anonymous users
connecting directly to the API App should not be allowed to retrieve
any information.
For contributors, they will be able to add documents using the Web App
when they are logged in. The documents will go through the API App
to be written to the DocumentDB
What are the suggested ways for handling anonymous users and authenticated users so both can use the Web App and the underlying API App successfully while blocking any use of the API App if it does not come from the Web App (or future mobile apps)? I only want anonymous users to be able to retrieve information when using the Web App.
The API App is developed in C# .NET 4.5, and the Web App will be the same. I'm not planning on writing my own authentication since the Azure Gateway takes care of this, but it only has the options of Public (Anonymous), Public (Authenticated), and Internal. Public (Anonymous) lets everyone in, while Public (Authenticated) blocks the anonymous users that I would like to have read only access. I'm very new to dealing with Authentication so I'm not even sure if this is possible without having to write my own authentication engine.
For clarification, this question is purely for Authentication between the Web App and the API App.
Thanks,
My app is architected as follows: I have a web service (running on GAE, not very relevant to this question) and the data that this service contains is made available through a website and through mobile and desktop apps.
Currently, the user authenticates to the website via Google ClientLogin and the apps authenticate/get authorized via GAE's built-in oauth provider. (OAuth is being used here mostly for authentication, my app doesn't actually use any external data via OAuth other than the user's unique ID and email address.)
What I'd like to do is expand the number of services that users can use to login. Because of the complicating factor of the apps, it seems I need OAuth. But I can't really properly conceptualize how this flow should go.
Lets take Facebook as an example. When a mobile app goes through the Facebook oauth flow and acquires an access token, this isn't enough - because its my service, not the app, that actually needs to talk to facebook to retrieve contact info and a unique user ID. This leads me to think that the OAuth process needs to happen in the context of my service, and not the mobile app. My service then becomes the consumer and Facebook the oauth providor, and the service holds on to the oauth access token, this happens when a user sets up their account for the first time.
If this is the correct approach, where does that leave authentication for the apps? What happens when the user already has an account and installs a fresh instance of a mobile app? I imagine also going through the oauth process, matching up credentials with the data already stored by my service, and then issuing my own "access token" to the app from the service, to authorize that instance of the app. This seems convoluted and hackish.
I'm sure I can't be the only person who is in effect "borrowing" the account system of a third party for a mobile app with a backend, but I really don't see what the proper way to do this is.
What am I not seeing and/or getting conceptually wrong?
A few colleagues and I once did a project quite similar in nature, back in university. We authenticated our users through either Facebook or Foursquare, using their respective OAuth APIs.
The native Android version of the app opened up a WebView with the OAuth provider's start page, which redirected back to our service after authentication. Then our service did a request for the OAuth token from the OAuth provider (Foursquare has some pretty simple instructions). When we got that token, we set up a session using cookies, which we could access from the app.
To validate sessions, we just checked whether the access token was still valid with the provider. We also used the respective providers' unique user IDs to distinguish users.
So yes, what worked for us is: Make the app authenticate & authorise your service, not the app itself.