Pelo que entendi do seu relato, o problema não é exatamente técnico, mas sim a complexidade que o Google passou a exigir para algo que antes era simples.
Antes (~2015–2018), dava pra usar notificações push do Gmail via Pub/Sub direto no Apps Script usando o projeto padrão do Google, com pouca configuração. Hoje isso mudou bastante por causa de questões de privacidade (GDPR, etc.).
Agora você precisa:
E o maior problema:
👉 Se ficar em modo de teste, os tokens expiram em 7 dias
👉 Ou seja, a automação para de funcionar e exige reautorização manual
Isso quebra totalmente o propósito de automação contínua.
Resumindo: o Google aumentou a segurança, mas acabou deixando o fluxo bem mais burocrático — até para casos simples e individuais.
A sugestão que você trouxe (transformar o Pub/Sub em um Advanced Service no Apps Script) faz bastante sentido, porque simplificaria muito o uso sem comprometer tanto a segurança.
Hoje, na prática, ficamos entre duas opções:
DimuDesigns <dimud...@gmail.com>: Apr 19 04:32PM -0700
This issue has a fairly long history. Allow me to elaborate.
Gmail API Push Notifications
<https://developers.google.com/workspace/gmail/api/guides/push> was
released in 2015 and for around 2 to 3 years, it was possible to use this
feature directly from a consumer-grade/personal account using the default
Google-managed GCP project linked to a GAS project WITHOUT jumping through
too many hoops.
Back then we could access the google-managed project from the google
developer console, enable the Pub/Sub API, create a Pub/Sub topic to
receive real-time notifications from Gmail for various events (new incoming
email, sent email, etc.) and wire up a GAS Web App as the target for a
Pub/Sub push subscription to process said notifications.
That ended in 2018, with the shift towards a stronger stance on User Data
Privacy. From then on, users were no longer able to access google-managed
GCP projects from the Google Developer console and the ability to enable
the Pub/Sub API on the default Google-managed GCP project was also
disabled.
Today we have to link the GAS project to a GCP standard project, and by
virtue of having services with restricted scopes (Gmail), go through a
verification process for scripts intended solely for private/individual use
on a consumer account.
In this instance, I think Google overcorrected in their efforts to secure
their platform in order to comply with GDPR, CCPA and other regulatory
bodies.
While the verification process makes sense for apps that will be deployed
publicly - for scripts meant for private use on a consumer account - those
steps are superfluous. Some try to workaround this by staying in "testing"
mode (applicable to GAS projects linked to a standard GCP project).
However, OAuth refresh tokens and access tokens expire after 7 days,
forcing users to manually reauthorize their scripts - not a good approach
if your goal is to automate a process.
I think there is a better middle ground, where Google can be compliant and
where users with consumer accounts can enjoy the benefits of services that
leverage API Push Notifications using Pub/Sub.
The Solution: Make Pub/Sub an Advanced Service.
As an advanced service, the default Google-managed GCP project can
transparently enable/disable the Pub/Sub API and allow devs to use the
service seamlessly with far fewer steps.
If you are in agreement on this matter, upvote the issue using the link
below:
https://issuetracker.google.com/issues/504194149
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to google-apps-script-c...@googlegroups.com.