In February 2024, Google made a change in Google Sheets to enhance data security. Now, users must provide explicit consent before Sheets can connect to external data sources. This change aims to prevent unintentional data leaks and improve overall data loss prevention within Google Sheets.
Impact on Users:
When manually adding or editing certain IMPORT functions (IMPORTHTML, IMPORTXML, IMPORTFEED, IMPORTDATA) and the IMAGE function in a Google Sheet, a warning banner will appear blocking sending a receiving data until the user gives consent. To enable this functionality, users need to click “Allow access.”
Impact on Developers:
As highlighted in the first source post by Justin Poehnelt, this change caused issues for developers who programmatically create Google Sheets and automate tasks, such as generating PDF documents as the IMPORT and IMAGE functions were blocked.
Solutions for Developers:
Fortunately, Google introduced an update to the Google Sheets API to address this challenge. Developers can now enable external data access programmatically by setting the importFunctionsExternalUrlAccessAllowed property in the Google Sheet metadata. This allows specific IMPORT and IMAGE functions to work without manual user consent.
For the IMPORTRANGE function, a similar API property is currently unavailable. However, an unofficial workaround exists that involves calling an undocumented endpoint using Google Apps Script as detailed in the second source post by Kanshi Tanaike.
Future Expectations:
As Google continues to prioritize data security, there will likely be further enhancements to data loss prevention controls within Google Workspace. Hopefully, future updates will also include official API controls for IMPORTRANGE and other functions to facilitate legitimate data access for developers while maintaining data security.
Learn about the different options for making API calls in Google Apps Script web apps: `google.script.run` and GET/POST endpoints (`doGet` and `doPost`). Understand their strengths and weaknesses to choose the best approach for your project.
Google Apps Script web apps are a popular way to publish user interfaces for automation processes. I’d never really considered the decision between google.script.run and GET/POST endpoints (doGet and doPost) when making server side calls, but as outlined in this post from Justin Poehnelt there are scenarios where both of these approaches might be most appropriate. Justin also provides some useful code snippets to help you get started with both methods. Follow the source link to read more…
A generic Apps Script memoization function can be written to cache any function.
We’ve featured a couple of Apps Script optimisation techniques in the past. This example from Justin Poehnelt uses a technique found in many coding syntaxes of ‘memoization‘:
In computing, memoization or memoisation is an optimization technique used primarily to speed up computer programs by storing the results of expensive function calls to pure functions and returning the cached result when the same inputs occur again
For more background on when and why you might use ‘memorization’ you can read about Memorization [sic] in JavaScript. In the case of Google Apps Script developers have opportunities to integrate the built-in Cache Service and Properties Service to memorize function results in the context of the script, document or the user.
In the example provided in the source post by Justin it defaults to CacheService.getScriptCache() to store the memoized results but it would be easy to change this to CacheService.getUserCache() or CacheService.getDocumentCache(). With a little modification you could also include Properties Service.
Google Drive broke the ability to embed images with the /uc path. Here’s how to embed images from Google Drive in your website.
Previously Google Workspace developers could use a /uc path for embedding images and other files hosted in Google Drive. For example, images could be embedded in websites and emails using markup like:
To my knowledge this was never an officially documented endpoint, but widely known about and shared within the community. Back in October 2023 Google announced Upcoming changes to third-party cookie requirements in Google Drive, which has started rolling out from the beginning of 2024.
The impact of this change is it breaks /uc embeds and these have started returning 403 errors. There is no reference to the /uc endpoint in the original announcement, which is why I think many people are only just finding out about the impact now. Google’s official guidance is to move to <iframe> with Google Drive publish and preview links. This post from Justin Poehnelt discusses the options and limitations for images.
Avoid downloading private service account keys by using impersonation in Apps Script to obtain access tokens.
For Google Workspace Admins you can gain super powers (and super responsibility) using Google Cloud project service accounts. A common scenario is using service accounts with domain-wide delegation to make API calls impersonating Google Workspace users. With this you can do things like set a user’s Gmail settings including signatures, authenticate as a user in Google Chat and much more.
A quick way to use a service account is to download a JSON key. The challenge then given the potential capabilities of service accounts is securely storing the JSON key. A alternative approach, which is explained in this post by Justin Poehnelt, is using Apps Script to create and fetch a short-lived credential for your service account.
Short-lived credentials are highly recommended for applications requiring robust security and precise access control for service accounts, reducing the attack surface and the risks with accidentally exposing static secrets.
You can find out more include code snippets/setup in Justin’s post which also links to the support documentation.
