I am working on adding Google reCAPTCHA v3 to FreeToastHost, a free forms & template based website generator/content management system specifically made for use by Toastmasters public speaking clubs around the world.
One challenge I have in implementing this is that in addition to our use of a root domain and subdomains for accessing each club's website, we also support each club purchasing their own "custom website domain" through a registrar which they they tie to our server's IP address via their DNS settings.
We do require that each club save these "custom domain names" in the system (gets stored in our db) so we can still generate their website by looking up their custom domain in our db to fetch their content. At this point we have about 80 clubs of the 12000+ using the system that also have custom domains.
I will not know these custom domains in advance, so I have had to just register our root domain for Google reCAPTCHA v3, shut off the domain checking setting because of the custom domains, and resolve to do our own domain checking.
I would prefer that Google do the domain checking, but without an API to add domains programmatically / dynamically and with their 50 domain limit per key-pair, I am just not sure what else to do other than doing our own domain checking.
Anyone have any fresh ideas on this?
Related
When attempting to use Google federated authentication login button for a Google webapp, error message identified mismatch with related URI and javascript host domains. Solutions, as in this 2019 post (Get gmail address using Google Apps Script, Error: redirect_uri_mismatch) weren't working for me.
I then found this recent article: What is the Authorized Javascript Origin for a webapp powered by Google Script?
I understand it to say that, due to recent actions by Google, it is no longer possible to use the Google authenticator for a Google webapp because redirect URI and javascript origin host domains "cannot be googleusercontent.com”, which is the host domain for Google webapps.
So, my question duplicates earlier posts (i.e., 2019) but in new circumstances. The conclusion of the recent post I've cited seems so radical to me that I'm seeking confirmation, or explanation of how I am misunderstanding it.
As background: I need the webapp to operate under the "(me)owner" account for connectivity to owner spreadsheets, but also need the user's Gmail address (required) for application access control (no other access to user Gmail account; users not all in a shared Workspace domain). Google login would provide the user Gmail address. So, before totally abandoning this solution, I hoping to get additional clarification.
According to the official docs, it's not possible to use Google Sign-In for Websites, and this post from the Google Apps Script Issue tracker Fail to Add *.googleusercontent.com into Authorized JavaScript origins as Google Apps Script uses googleusercontent.com
To achieve your goal, as I mentioned in your previous question, you might use the UrlFeth service to call the Google Sheets API to do the connectivity to your spreadsheet and setting the web app as the user instead as you.
From https://developers.google.com/identity/protocols/oauth2/web-server#uri-validation
Domain
Host TLDs (Top Level Domains) must belong to the public suffix list.
Host domains cannot be “googleusercontent.com”.
Redirect URIs cannot contain URL shortener domains (e.g. goo.gl) unless the app owns the domain. Furthermore, if an app that owns a shortener domain chooses to redirect to that domain, that redirect URI must either contain “/google-callback/” in its path or end with “/google-callback”.
Related
How to Properly Configure GAS Web App (as another user) to Execute GAS API Executable (as me) using OAuth2?
User access request when GAS run as the user
While true that you can no longer add googleusercontent.com, you may be able to solve this by using two webapps and managing authentication/authorization between the two:
Webapp#1:
Run as: Me
Access: Anyone even anonymous
Webapp#2:
Run as: User
Access: Anyone
You may be able to create a jwt token from webapp#2 and verify it on webapp#1. As it is a custom solution, security may be questionable.
References:
Authenticate with a server - Here, webapp#1 acts as server and webapp#2 acts as client.
ScriptApp.getIdentityToken()
I am in the process of implementing an OAuth2 flow for a sensitive scope in my chrome extension. In order to remove the 'unverified app' warning in the OAuth2 popup I must verify the app in the Google Cloud Console.
The verification form requires 'Authorized domains' though, and it does not accept a chrome extension URL of the form 'chrome-extension://', neither does it accept a URL of the form '.chromiumapp.org'.
Is it possible to provide another domain I own as the authorized domain, and still initiate an OAuth2 flow from the chrome extension using chrome.identity.getAuthToken({interactive: true}...?
I think you need to read though the documentation on application verification
The very first one mentions that your domain must be authorized and verified in search console. The files must also be hosted on your verified registered domain.
It clearly states that
Links to the Google Play Store or Facebook are not considered valid application homepages.
The only requirements are that
Domain is registered in Search console.
Home page listed in the auth screen is relevant to your app.
So i don't see any reason you can't put it on one of your other domains. Just make sure that it qualifies for this clear its relevance to the app you’re verifying
Relevant points in the documentation.
Verify ownership of your project’s authorized domains using the Search Console. Use an account that is either a Project Owner or a Project Editor of your Cloud Console project.
Then the section about
Make sure that your homepage meets the following requirements:
Your homepage must be publicly accessible, and not behind a sign-in page.
Your homepage must make clear its relevance to the app you’re verifying.
Your homepage must be accurate, inclusive, and easily accessible to all users.
Links to the Google Play Store or Facebook are not considered valid application homepages.
There is also the Privacy posily
Make sure that your app's Privacy Policy meets the following requirements:
The Privacy Policy must be visible to users, hosted within the domain of your website, and linked from the OAuth consent screen on the Google API Console.
The Privacy Policy must disclose the manner in which your application accesses, uses, stores, or shares Google user data. Your use of Google user data must be limited to the practices disclosed in your published Privacy Policy.
I have a video that goes though the application verification process. Google OAuth. What you need to know about verification in 2021.
Th company I work for recently switched to using Team Drive and we had multiple applications that would interact with Google Drive using the Google Drive API. The API calls would be authorized using Google Service Accounts and access to specific files would be given to an app by sharing the file with the Service Account email in the same way you would share a file with a normal user. Now that we've switched to Team Drive I'm unable to grant access to the Service Account as the email address associated with it is not considered part of our organization. I've also looked into adding the Service Account as a normal user in our organization through the Google Admin dashboard, but it only allows me to create new users, not include existing ones. The only solution I've found is to enable sharing with external parties which would allow me to share Team Drive files with the Service Account, which would be considered an external party. This solution is risky and incorrect as the applications using the Service Account are part of our organization. We also do not want enable sharing with external parties in general for security reasons.
I've followed the steps described in How to access Team Drive using service account with Google Drive .NET API v3 and they work, but as mentioned above they require sharing with external parties to be enabled which we do not want.
The ideal solution would be for the Service Account to be considered part of our organization, but I cannot find a way to do this.
I've also tried delegating Domain-Wide Authority to the Service Account as described in https://developers.google.com/identity/protocols/OAuth2ServiceAccount#delegatingauthority, but as far as I understand this is not what I want as this will allow the Service Account to impersonate other users, but the reason we have a Service Account is for carrying out processes that happen automatically and which aren't associated with a specific user.
I've also followed the steps outlined here https://developers.google.com/admin-sdk/reports/v1/guides/delegation#delegate_domain-wide_authority_to_your_service_account for white-listing a specific API service through the Google Admin Security interface, but this doesn't seem to do anything, and I'm not sure what it is supposed to do as I have already enabled the Drive API for this Service Account in the APIs & Services dashboard where I originally created the Service Account.
We're using R and so I've been using the googledrive package which has functions for working with Team Drives like:
googledrive::drive_find()
googledrive::team_drive_find()
googledrive::team_drive_get(id = "team-drive-id")
I would expect to be able to see the team drive, but I guess this is not possible unless the Service Account email is a member of the Team Drive which is not possible because the Service Account (which is linked to our organization through its owner) is not considered part of our organization.
I had the exact same issue and after trying a lot of approaches, landed on the solution below (++):
Create a group in Google Workspace. You can add any external identity/email to a group, since they can be used for multiple things. So add the role account to this group.
Google has recently come out with "Trust" rules, that allow granular sharing. You can share with a group. So I created a trust rule that allowed sharing of any data source (easier than restricting who can share since file/shared drive ownership affects this rule) to only the group that contains the service account. Now external sharing is permitted, but only to the role account.
Lastly, share the drive with that role account.
++ Note that I also had followed the majority of steps above including the GCP project creation and domain-wide delegation before this portion, but was similarly stuck getting a 403 for access rights.
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.
I have a website I developed for a client. One of the pages displays a list of street addresses, for which I also have LAT/LONG data. The client requested to add a little map next to this list with a marker for each address.
I would like to use Google Maps API v3, but I have a problem registering client's internet facing URL, which has a form of "ip address:port" (i.e. something like http://123.45.67.89:555) and which I - naturally - do not own and do not have domain admin access. Likewise, their domain admin - whoever s/he is - does not and will not have access to my Google API project for which I'm trying to register the key.
So far I was able to register the client id for local development in a form of http://localhost:5555, but when I'm trying to add the client's URL I'm getting an error
OAuth 2 redirect URL "http://123.45.67.89:555" is invalid.
I searched for solution for this problem and found a suggestion to whitelist the URL in the Google API Console. Yet when I'm trying to add this URL to approved domain list ("notification endpoints") I'm only getting another error:
You do not have access to the following domain:
http://123.45.67.89:555
which is, of course, true. The documentation also says I cannot register a domain I don't own.
So, my question is: how do I register a Client ID for Google Maps API V3 for the client's URL to which I don't have domain admin privileges and whose domain admin doesn't have access to my API project?
Thank you!
Nikolai
You can create a view of the table (File | Create View ...) and own the view (https://support.google.com/fusiontables/answer/171206?hl=en) - thus enabling you to have your own version of the table which is in sync with changes.
As a footnote remember to deal with Cross Origin Resource Sharing (CORS) in your API project by using JSONP for example (https://developers.google.com/storage/docs/cross-origin).
If your are using Google Maps API v3, there is no need to use Google API Key. Simply use below script.
<script type="text/javascript" src="http://maps.googleapis.com/maps/api/js?sensor=false"></script>