I am deeply into learning about App Script but there is so much the Google has to offer I'm a bit overwhelmed at figuring out what I need.
I'm designing an online volunteer application work-flow and eventually other things for a non-profit organization.
Here is how I envision the process flow going.
New user comes up first Web App page asks for first last middle and email address
First Last Middle are used together in some way to create a domain log on for the user using the provisioning API (already figured this part out) while prompting the user to create a password
At this point the user is passed to the actual application web app that runs only for domain users so that the relaxed rules of app script for user behind a domain can be leveraged and also so the entire ebb and flow of information stay behind our domain.
Now where I am unclear on is the jump from step 2 to step 3.
What would be the best and most painless (for the user not me) way to put together the transition from running the entry point app that creates the new users domain account as essentially an anonymous user identity to running the domain level app AS their new domain user identity.
I've been studying OAUTH but it seems that is more for external integration with things like drive and youtube etc. My goal with this project is to have everything (aside from things like client side validation and jQuery) running from Google's Cloud.
In #2 i asusume you have a pool of unused gapps accounts.
In #3 you need to get the user logged in in gapps first . For that you need to show a special login url that will redirect to fhe other app. Another is to do a manual oauth flow and use the redirect url to get to fhe new app.
Related
I was asked by a potential client if I can have my software interact with Esri/ArcGIS Online.
Use case: users is logged into SomeRandomSoftwareApp and is looking at a Widget, this Widget includes an Esri asset id, the user clicks a link that passes that ID to Esri/ArcGIS Online and behind the scenes the user is logged into Esri and they see the data associated with the Esri/ArcGIS Online.
Thanks, Keith
If I understand correctly, you have two options for this: API Keys or Application Credentials.
The first one, is a permanent token generated by the owner of the data that will allow the application easy access to it. This is still in beta, and it was not ready for use the last time I check some time ago.
The second one, the owner of the data will generate credentials for your application. With this credentials you will have to request a token each time you want to access the data, all this via OAuth 2.0.
Check the docs for more details ArcGIS Services - Security
As title says...
BUT, I've made a web app for output some result based on a data search using parameters submitted in a google form in my google site.
I work in a school so no way that all teachers has, or want to use, or want to waste time just for know which labs are available in some time slots.
I really need that everyone can run web app ... obviously I deployed it with access anyone, even anonimous but
https://sites.google.com/itsluigicasale.gov.it/prenotazionilab/trova-un-laboratorio-libero
have I made some errors?
is there any workaround?
I'd like to use it without access or ask for permission for the users
We are using G Suite API with our Micro service for document editing, and we have a different data center and also different db. now once user comes to my application and trying to open document first time then google give consent screen based on that i can get refresh token and access token and i store into one data center.
But problem is that if user comes from another instance which use different data center with different db and user trying to open document with old credentials then google doesn't give any consent screen so i am not getting user's refresh token.
1) So is there any way to get refresh token without using consent screen?
2) Is there any way to identify if user comes from different sub domain then i need to provide consent screen for that?
It might be possible to use the prompt=consent option to force a re-prompt for auth, even though the user has already authorized your app.
See https://developers.google.com/identity/protocols/OAuth2WebServer#creatingclient
You can identify the user's domain using the hd parameter [1] and you can request a refresh token without the consent screen after the domain admin has configured domain wide delegation by installing your application from the GSuite Marketplace [2].
[1] https://developers.google.com/identity/protocols/OpenIDConnect#hd-param
[2] https://support.google.com/a/answer/172482?hl=en
When you request an OAuth Flow (access_type=offline`), a Refresh Token is returned to your application. This only happens once (obtaining a Refresh Token). Your application is expected to save the Refresh Token for future needs.
In your use case, one of your systems completed the authentication and the user has moved to a different system. You will need to reauthenticate with prompt=consent, access_type=offline. You will not get another Refresh Token without reauthenticating.
I spent a lot of time on this issue last November. Here is a link which has lots of details on this problem.
Any application can only have one valid refresh token for a user. You can request for a new refresh token using the prompt=true&access_type=offline on the request as said by #John. But every time the previous one will become invalid.
Based on you comments on the other answers, I'm assuming creating a new micro service that returns the token to the one being used is not a possibility (that would be my recommendation)
You asked "to identify if user comes from different sub domain"...
If those applications are for end users of gmail.com accounts, you can treat them as different applications and configure different projects on the developer console.
It will be a bit of a pain when enabling new APIs, I would recommend doing that from a script that replicates to all application needed.
If your end users are from companies using GSuite, you can have your app installed as domain-wide application (either manually or from GSuite Marketplace). In that case you can use just client side authentication to get an id_token, send the token to the server and use a service account to impersonate the user in any given service without worrying about any token from them.
I'm a hobbyist student developer playing around with the Actions on Google to create a simple "text adventure" game on Google Home. Since Google Home will be speaking to the player rather than the player reading the text, I'm hoping this will create an experience similar to the "Dungeons and Dragons" roleplaying game, with the computer working as the "Dungeon Master." With the natural language assistance offered by API.AI and Actions on Google, it seemed like a good fit, since the player can respond "naturally." Here's an example of an Amazon Alexa skill that does essentially what I'm going for.
However, every time I boot up the game, it's always a new game. I'd like to store a savegame with the user's previous state in a JSON file hosted on the user's Google Drive -- Since I'm just a student doing this for fun, I don't actually have an official website or anything beyond a free Heroku server I'm running the app from, making storing saves on my end pretty much out of the question.
I've walked through the Google Drive REST quickstart for Node.js, and I've gotten that working in the console just fine. The only problem is in that quickstart, the user has to click a link to authorize the application to read the stuff in their Google Drive account, and I'm not sure how I'd be able to "click a link" and give back an access token via voice on Google Home.
Is there a way to do this via Google Drive? Or is there a better way to provide persistent data between sessions? I don't normally work in web development, so any help would be appreciated.
The bad news is you won't be able to get away from the need for a user to use his web browser to authorise your app to access his Drive.
The good news is that you only need to do this once. When your app requests authoirsation, it should specify "offline", which will result in you being given a refresh token. You should save this somewhere in your database of users. Whenever you need to access the user's Drive, you can use the saved refresh token to request an access token and you're good to go.
You have a few problems that you need to solve here, and while they seem related, they're not as related as you might hope:
You need to get authorization to access a user's Drive space
You need to authenticate the user's Home (so you know this person has come back)
You have to connect the two relationships - so you know what Drive space to use for the Home device that is talking to you
You've found the answers to (1) already, and as noted, you'll need to use a browser for them to authorize you to access their Drive. You'll then store the refresh token and will be able to access it in the future.
But that is only part of the problem. Home does not provide you access to the user's Google account directly, so you'll have to manage your own account mechanism and tie it to Home. There are a few solutions here:
Home provides anonymous user identity in the JSON sent to your webhook. You can access this using getUser().user_id if you're using the Actions API library, or access this in the data.user.user_id field in the JSON. While this is similar to a browser cookie, it only stores the user ID and can't store additional data. There is also no concept of "local storage". On the plus side, this ID is consistent across devices.
You can request user information such as their name and address. But it doesn't have anything unique or account information, so this probably isn't useful to you.
You can implement an OAuth2 server and do account linking. Note that this is the other side from what you need to do with Google Drive - you'll be providing the access and refresh tokens to authenticate and authorize access to your account and the Google Home device will send these tokens back to you so you can determine who the user is. You don't actually need to store account information - you can provide token information using JSON Web Tokens (JWT) or other methods and have them store account information in a secure way. Users will use the Google Home app to actually sign-in to your service as a one-time event.
In order to handle (3), you may be thinking that (1) lets you get tokens and the OAuth solution for (2) requires you to hand out tokens. Can the two be combined? Well... probably, but it isn't as straightforward. You can't just give the Google OAuth2 endpoints to Home - they explicitly block that and you need to control your OAuth2 endpoints. You may, however, be able to build proxy endpoints - but I haven't explored the security implications of doing so.
I think you're on the right track - using Drive is a good place to store users' information. Using Home's account linking gives you a place where they have to come to your web site to authenticate and authorize their Home, and you can use this to do the same for their Drive.
Retrieve/Update Google-Contacts from Apps Script (Spreadsheet)
Environment Desc:
We have a shared spreadsheet belonging to a domain-account "PrimContact" where we also manage our contacts.
The spreadsheet is shared with selected users in the domain with r/w-access.
Workflow so far: after making changes to the spreadsheet persist those changes through script-call.
This api-call was authorized via clientAuth and as of a few days that won't work anymore.
Through clientAuth we were able to allow all the users to manipulate the sheet and finally update
the contacts of the targeted contact (PrimContact).
Problem:
Reading up about deprecation of clientAuth I tried, and somewhat succeeded, to change
authentication to OAuth2. As I understand things there are two ways I can authenticate a
user. Through a clientAccount or via serviceAccount.
SideNote: The following two pages helped a lot in getting it done, especially for serviceAcc.
[1]client account with: https://github.com/googlesamples/apps-script-oauth2
[2]service account auth with: https://github.com/mcdanielgilbert/gas-oauth2-gae
For that to work I added a project to PrimContact-user and created both a web-account and a
service account. Using aforementioned scripts as a starting point authentication works too, but
in the end it's not what I am trying to accomplish.
Client Account: the script is calling the api (contact-api) with an access token for the currently
logged in client although I provided the clientId of the PrimContact-user. Now I COULD run the script as PrimContact-user beforehand and store the token
in the document. If the access-token has not expired yet the other users can work with this
token just fine and therefore "operate" on the PrimContact-data. But as soon as the token
expires I would have to call the script as PrimContact-user again, which is not to very comfortable.
Service Account: got it working with gas-oauth2-gae, but the contact-list is empty. The call
itself is successfull though. I guess this is due to the service account not being tied to
the PrimContact-user although the project is associated with this user?
Goal:
Making an api-call (contacts) inside google-apps-script(spreadsheet) used by different users and
manipulate contact-data of a different account, i.e. the account who originally shared the spreadsheet.
Maybe I'm getting the whole idea of OAuth2 completely wrong, so far my understanding of the
clientAccount-thing is that the currently logged in user allows the project (which belongs to the
PrimContact-user) to manipulate the data of the currently logged in user.
What data the service-account-authenticated call is manipulating.. I'm not quite sure..
If it helps I can add the code-snippets, but as everythings "working" & still not doing what
I really need it to do I'm not sure if it's helpful.