I am trying to migrate my current GSuite Add-on script project to V8 engine as per Google's recommendation. I got everything working except that whereever I use:
CardService
.newAuthorizationException()
.setCustomUiCallback('create3PAuthorizationUi')
.throwException();
Add-on is stopping with a runtime error.
Any ideas?
Problem
You are missing the required setAuthorizationUrl method in the chain. I am not sure why switching back to Rhino runtime works for you, probably the error detection is improved.
Also, since we do not have the code for the logout function that causes the error, you might have another migration issue unrelated to authorization.
Solution
Your snippet should look something like this:
const authUrl = "https://example.com";
CardService
.newAuthorizationException()
.setAuthorizationUrl(authUrl)
.setCustomUiCallback('create3PAuthorizationUi')
.throwException();
Issue Tracker note
The issue I created on the issue tracker is now closed as intended behavior. Turns out the URI provided to the method (see authUrl) must be a valid URI. Technically, it accepts invalid and unreachable URIs, the only requirement is that the argument must be a string.
Because during testing I relied on the ScriptApp.getService().getUrl() method call chain on a new project not deployed as a Web App, therefore the authUrl held null.
Related
I'm attempting to use Google Sign-In with a firebase function following Google's documentation for Google Sign-In for server-side apps, however I'm running into a redirect_uri_mismatch error (unlike the examples in that documentation, I am using Google's nodejs SDK).
The general flow I'm following is to use google's javascript SDK to request an offlineAccessCode() from a user, send that access code to the server (firebase function), use the access code to get an access token and refresh token, and save the refresh token for later use (this is the flow outlined in the documentation).
It might seem like the meaning of the term redirect_uri_mismatch is self-explanatory, but, as stated in the linked documentation, The Authorized redirect URI field does not require a value. Redirect URIs are not used with JavaScript APIs. That line comes from the section "Step 1: Create a client ID and client secret" and is explaining how to configure the OAuth client credentials. This is the only time in the documentation that a redirect uri is mentioned, and there is no indication that a redirect URI is needed when the server uses the authorization code to fetch an access token.
Indeed, the concept of a redirect uri doesn't seem to make sense in the context of a cloud function using an access code obtained from a client. If the server needs to supply a matching redirect_uri as the javascript client (which doesn't seem to be specified anywhere), I'm not sure what redirect_uri the javascript client uses.
So with that background, does anyone have any idea how to solve this redirect_uri_mismatch error?
Or, more generally, any pointers on implementing this auth flow (my cloud function is written in javascript using the google nodejs sdk). I'm finding it very hard to debug this issue.
Update
I realized that the reason why the error message says redirect_uri_mismatch is because I had been testing various values as redirect_uri. When I remove the (optional) redirect_uri param from the request, the response from google's servers is invalid_request: Missing parameter redirect_uri. So google's making it clear that it wants a redirect URI, even as the documentation seems to imply that it isn't necessary for this auth flow. As a larger problem, the documentation doesn't seem to describe how to set up a redirect URI for an auth flow on a single page app.
Ah HA! The answer (as given in this other S.O. answer) is to set the redirect_uri to "postmessage" on the server (firebase function in my case). I have no idea where this answer came from (i.e. I haven't been able to find it in the docs), but it works.
I use serverless framework to manage my cloud functions. Some of them are of HTTP type. Recently, all the HTTP functions started to fail with 403 error. No matter if you enter a URL in a browser or trigger it with the cloud scheduler. The only place where it works is the testing tab of the function in the cloud console, when you click the "Test the function" button.
So, I did not find the reason for the error but it fixed with removing the function and redeploying it.
serverless remove
serverless deploy
Is it possible that the Identity Aware Proxy has been enabled for the Cloud Function URLs? If you navigate to Cloud Console and then to "Security" and "Identity-Aware Proxy", you should be able to see the IAP settings and whether the Cloud Function is being protected by IAP.
If that is not the cause, I would advise putting some logging in your function that would make it clear whether the function is getting called and then returning a 403 somewhere within the execution of the function (indicating a problem with the function, itself, rather than the identity infrastructure) or if the function is never getting called (the 403 is being produced outside of the Cloud Function), in which case you may need to reach out to Cloud Support for help with this (if IAP isn't the cause).
Google Cloud Functions added some new IAM functionality, not sure how recently, and now new functions don’t have public access by default.
Incase someone else comes here I thought I'd share this information here.
To allow your function to be invoked you first have to add permissions to the function, you can do this by selecting the function in the functions list and adding allUsers to the Cloud Invokes role, you can see the step by step at:
https://lukestoolkit.blogspot.com/2020/06/google-cloud-functions-error-forbidden.html
Our application uses the drive.file scope to make sure we only can see files of our users that have been created by our application.
However, a 'list' call returns files that have been shared with the user even though they are not created by our application.
That can be easily verified in the "Try it!" section of files/list API documentation.
Authorize with drive.file scope and run a simple list query without any parameters. That should return an empty list but in my case returns dozens of files that have been shared with me.
There was the same issue before (a slight variation only affecting queries with q parameter set): Listing files with search query returns out-of-scope results (drive.files.list call, using drive.files scope)
It has been fixed in the meantime but now it seems to be back for all list queries. It's problematic not mainly because it breaks our app that expects nothing but its own files. There is the privacy problem because I can suddenly see the file names of our users' private data, which they have never agreed to.
I believe this issue is due to the behavior of API Explorer, not Drive API itself. If API Explorer already has a token with OAuth scopes capable of making the call, it will use that so if previously given API Explorer a scope that can see all user files, you'll get them all back. Try revoking ALL Explorer tokens for your account at:
https://accounts.google.com/b/0/IssuedAuthSubTokens?hl=en
then, after clearing all cookies/sessions for developers.google.com, try creating a new token with ony the drive.file scope and attempt your API call again.
You should also note that files that are publicly shared will be returned.
I went through the Quickstart on how to upload a file to Google Drive (for Android) and everything works fine. However, it isn't clear whether I am responsible for storing tokens and handling exceptions if they expire. Does the SDK code used in the Quickstart handle this for me behind the scenes?:
https://developers.google.com/drive/quickstart-android
If I regularly call this code (taken from the Quickstart):
credential = GoogleAccountCredential.usingOAuth2(this, DriveScopes.DRIVE);
credential.setSelectedAccountName(accountName);
service = getDriveService(credential);
and then call some drive method, will it eventually generate an exception when the token expires or does the SDK code catch this internally and automatically attempt to retrieve a refreshed token?
To be even more specific, am I required to implement the code shown here:
https://developers.google.com/drive/credentials
What also isn't clear to me is the difference between an access token and refresh token. Then there is "short lived" tokens and "long lived" tokens. Kind of confusing.
On Android, when you use Google Play Services, all of the work is handled for you, including getting the token and refreshing it. This is explained in the quickstart guide that you have linked, and there is nothing more that you need to do.
I'm playing around with AppScript and try to get an oAuth 2.0 access token.
Any sample out there how to get this working in AppScript?
I am working on a cleaner tutorialized version of this, but here is a simple Gist that should give you some sample code on how things would work -
https://gist.github.com/4079885
It still lacks logout, error handling and the refresh_token capability, but at least you should be able to log in and call a oAuth 2 protected Google API (in this case its a profile API).
You can see it in action here -
https://script.google.com/macros/s/AKfycby3gHf7vlIsfOOa9C27z9kVE79DybcuJHtEnNZqT5G8LumszQG3/exec
The key is to use oAuth 2 Web Server flow. Take a look at getAndStoreAccessToken function in the gist to get the key details.
I hope to have this published in the next few weeks but hopefully this will help in the mean time.
UPDATE - adding in info on redirect_uri
The client secret is tied to specific redirect URIs that the authorization code is returned to.
You need to set that at - https://code.google.com/apis/console/
The highlighted URI needs to match the published URI (ends in /exec). You get the published URI from the script editor under Publish -> Deploy as web app. Make sure you are saving new versions and publishing the new versions when you make changes (the published URI stays the same).
I've modified the example above to use the newish state token API and the CacheService instead of UserProperties, which is now deprecated. Using the state token API seems to make things a little more secure, as the callback url will stop accepting a state token after a timeout.
The same caveats apply. Your redirect URIs have to be added to your (script) project in the developer's console, meanwhile you have to yank the CLIENT_SECRET and CLIENT_ID from the console and paste them in. If you're working within a domain, there don't seem to be any guarantees on what URL will be returned by ScriptApp.getService().getUrl(), so I wound up basically having it get the address dynamically, then waiting for to fail on the the (second) redirect, and then hard-coded the resulting URI.
https://gist.github.com/mclaughta/2f4af6f14d6aeadb7611
Note that you can build an OAuth2 flow using this new API, but it's not a complete sample yet:
https://developers.google.com/apps-script/reference/script/script-app#newStateToken()
In particular, you should not pass 'state' directly to the /usercallback URL yourself, because the OAuth2 service provider is responsible for round-tripping the 'state' parameter. (Instead, you pass 'state' to the auth URL, and the service provider automatically attaches it to the callback URL.)