I work a lot with AppsScript within my workplace. I've built lots of custom OAuth2.0 flows within AppsScript, that allow the application to call Google's REST APIs, and I've also worked with enabling the 'built in' API interaction objects (GmailApp, CalendarApp, etc). If you enable any of the built in APIs, the script editor adds the relevant scopes to the project information, and then asks the user for permission to interact with these APIs, when the web app first loads.
If I need to interact with both REST APIs and the few built in API calling objects, the user needs to first grant permission to the built in API scopes, then has to follow a separate OAuth flow, for the REST APIs. This makes for a really ugly user experience.
Is there a way to add REST API scopes to the list of scopes within the project information, so that when the user first loads the app, it asks them to grant permission for ALL scopes that the project will need? I could then retrieve the users oauth token from the script session with ScriptApp.getOAuthToken(), and use that in all external REST API calls.
EDIT (~12:00:05 18/DEC/15):
Please note, I already know how to enable APIs through the Developer Console Project that's linked to the AppsScript project - I want to find a way to add ALL APIs that are enabled to the Scripts properties, so that when the user launches the app, it asks them to grant permission to access all enabled APIs on their behalf (even REST apis), so that I don't need a second manual OAuth flow / token for the REST APIs.
EDIT (~14:00:08 18/DEC/15):
I've also looked into the Import/Export functionality within Drive, documented here:
https://developers.google.com/apps-script/import-export
and can't find any way to alter the scopes (or supply any scopes) for the project, this way.
In apps script you can enable specific API if you go to the menu "Resources > Advanced Google Services". It will open a Popup with a list of API, but there you also have the option to go to the Developer Console with the project associated with your Apps Script project.
And from there you can get the necessary information (clientId, etc.) related to the same Apps Script project and use it in you OAuth flow.
If you already have a project with all the required configurations and all the necessary API already enabled, you can also link your current Apps Script project to that app, so you don't have to do the same again.
In the menu "Resources > Developer Console Project", a popup will open and there you will have the option to access the Developer Console, but also you will have the option to associate the current Apps Script project to any other app you already have.
Just keep in mind that when you are trying to use an API you will have to enable it in the "Advanced Google Services", both in the list that the popup shows as well as in the Developer Console.
After doing this, the access tokens will be related to the same app and the users will grant permissions only one time when enabling a new API.
I hope this helps.
Related
I have an app with SwiftyDropbox that function correctly, but I need to insert email and password for Dropbox every time that I use the app.
The app it's only for my use, it's not a security problem if the app auto-login in my account.
I don't find examples or documentation to make an auto-login with SwiftyDropbox. It's possible?
While the Dropbox API was designed with the intention that each user would link their own Dropbox account, in order to interact with their own files, it is technically possible to connect to just one account. We generally don't recommend doing so, for various technical and security reasons, but those won't apply if you're the only user anyway.
So, there are two ways to go about this:
1) Implement the normal app authorization flow as documented, and log in and authorize the app once per app installation. The SwiftyDropbox SDK will store the resulting access token for you, which you can programmatically re-use after that point each time using authorizedClient.
2) Manually retrieve an access token for your account and hard code it in to the app, using the DropboxClient constructor shown here under "Initialize with manually retrieved auth token".
I'm trying to make a chatbot with Dialogflow for Google Home. It requires the user to input a URL. Now it will definitely be a long and complicated URL which I can't recreate and I can't have the user speak into the google home.
The idea I had was that the user would input the URL on an agent on messenger. I store this on a Firebase database and then access it with a second agent.
Now the issue I have is authentication, I was hoping to use account linking on my google action with facebook. But I can't login to Facebook with google home. Or if I can, I can't find any documentation specific to that case. Facebook doesn't provide the necessary client ID and secret(as far as I can see).
I managed amazon and Gmail account linking with Alexa and an Amazon Echo. In those cases, you would have to login to google or amazon on the Alexa app or webpage. Then this will be integrated with your Echo and the skill will become usable.
Anyone have an idea of how I can make the link happen, if not then anyone have an idea as to how I can solve the overall problem?
This question has been left unanswered on other forums, but I was hoping to either get it solved or find an alternative.
There are three approaches to solving your overall problem - getting the URL manually entered and available to your Action. Two of them tackle it the way you've suggested - involving authenticating to Facebook and tying that to the Assistant account somehow. One solves it entirely inside the Assistant.
Account linking to the Facebook account
You've tagged firebase-authentication, so I'm going to assume that you're using it to do the auth and you've enabled Facebook login through it. This means your user has a "Firebase Account", but they log into that account using Facebook.
I will assume you have a way to get the URL from messenger once they're logged in.
The trick in this case is to setup Account Linking between their Firebase account and their Assistant account. This is done by setting up an OAuth2 server that has access to the Firebase accounts and will create authorization and refresh tokens that are given to the Assistant.
In the Action, you'll send the user to the Sign In helper, which will redirect them to your login page and send back a one-time auth code to the Assistant. The assistant will then use your OAuth2 server to exchange this code for auth and refresh tokens. Periodically it will use the refresh token to get new auth tokens.
When the user returns to the conversation through the Assistant, you'll be handed an auth token and you can use this to lookup the user. Since you also know their Facebook account, you can get the URL via however you planned to do so.
There are drawbacks to this method - it is very complicated, and setting up your own OAuth2 server is not for the faint of heart. You may be able to use something like Auth0 instead of Firebase Authentication to accomplish the same thing, but then you don't have the ease of access to the Firebase database.
Account linking to both Facebook and Google
In your Firebase account, however, you don't need to limit them to just logging into Facebook. You can have them use Firebase to record both the Facebook and Google accounts that they're using. This would "link" the two accounts together in your system.
With this, you don't need to setup an OAuth2 server. Instead, you can have the Assistant use Google Sign In for authentication. If the Google Cloud Project that Firebase is using and the Assistant are using are the same project, then once the user has logged in to your project's web page with their Google account, you'll get an identity token on the Assistant which will contain their Google ID. You can use this to match up with their Firebase account and get the Facebook ID and proceed from there.
But this is still a lot of work and kinda messy, jumping between systems.
Using just the Google Assistant (and maybe a web page)
If you're willing to make some assumptions about the devices your users are using, then you may be able to do it all just using the Assistant. The Assistant doesn't just run on the Google Home and other smart speakers, it also works on most current Android and iOS devices.
So you can detect if they have such a device available and, if they do and they're not currently on it, direct them to switch to that device when you need the URL.
If they don't have such a device available (perhaps because their version of Android is older), and you think this may be a common scenario, you may need to make another entry source available. This could be one of the solutions above, or you may want to just have a simple web page (done via Firebase Hosting and Firebase Functions, perhaps) where they log in using their Google account (so you get their ID) and you let them enter the URL. If you just need a URL - going through Dialogflow may be more complexity than you need.
I have hosted my REST services on API management and consuming those in the Azure Web app service which consists of only HTML pages, javascript files and CSS files.
I would like to know how to restrict accessing the REST endpoints of the API management only from the web app without Azure AD and OAuth setup.
Client side application sources are by design available in clear text to anyone using it. Any user can open developer tools in browser and look at code you've written to make app work. So even if you secure your REST API with some secret and use it in app code to talk to that REST API anyone in the world will be able to take that secret our of the app and call your REST API directly, and you would have no way to distinguish their calls from calls made by your app.
OAuth and AAD would work to a certain extent but even they allow you to authenticate user, not the app. Same user can easily trace calls made by your app to REST API and reproduce them in any other app, and you again would have to way of figuring that out.
I think your best bet is to throttle calls made by a certain user identifying it any way you want (even if by IP address).
You can use Certificate authentication from web app to api management. The ssl certficate thumbprint on you web app you can validate in api management policy.
I built a native Windows app (non Windows-Store) that uses the Facebook API.
I wanted to make it public which means going through their review process which means (among other things) selecting the app's platform.
Sadly a native Windows app is not one of the choices: Facebook app platform selection screenshot
I found 2 unanswered questions on SO on the same topic:
one
two
How should this be done in a proper way?
Thanks in advance.
PS:
I found a post a few days ago where the poster said he registered such an app by setting the platform to "web site" (I didn't keep the link).
This does not look like a good long term solution and also I don't have a domain to provide.
In short, you must set your platform to Web.
The reason for this can be found in the official documentation on building your native logon flow. There is no secure way of creating a logon flow without a server, as this would imply storing your App Secret inside your binary or app config file.
So the recommended (and only supported) way is to create a server which stores the App Secret and handles authentication for you. And use this server from the WebBrowser/WebView control which you embed into your native application.
This means you use the logon flow from a web browser via a custom server and you should have a domain for it (a domain is quite cheap nowdays, it should not be a problem). So you are building a web app embedded into a native app.
For a successful login review do the following:
Choose Web as your platform
On the Settings page in the Advanced tab choose Native App.
Create a screencast (Start your app, logon, use all the requested permissions and that's it. Do not edit it!) and upload it to the web (YouTube/Vimeo/...)
When submitting provide a link to your screencast.
I am working on a Soundcloud XBMC add-on. The add-on is open source, and written in Python. I would like to allow users to login to their SoundCloud account via the add-on, however it's possible to have XBMC instances running in an environment without access to a typical web browser (e.g. raspbmc, which provides no window manager or graphical browser by default). Is there a way to still allow users to authenticate with this add-on without requiring use of the 'SoundCloud Connect Screen' and without violating the SoundCloud API TOS?
This is not provided in theirs API, but after some digging into the libraries i figured it out.
Make a POST to: https://api.soundcloud.com/oauth2/token
with these params
grant_type=password&client_id=YOUR_CLIENT_ID&client_secret=YOUR_SECRET_ID&username=USERNAME&password=PASSWORD&scope=non-expiring
this will return non expiring token that you can use for future authenticated requests.