iterative / iterative/PyDrive2

Google Drive security update 2021- questions, how does it affect PyDrive2, how to deal with it

Abierto
#129 1 comentario 0 reacciones 0 asignados Ver en GitHub
question
Lenguaje dominante
Python
Estrellas
670
Forks
75
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

"Security update for Google Drive": https://support.google.com/drive/answer/10729743

1st paragraph says "_the security update will make Google Drive files more secure by updating their links to **include a resource key**_"

So I have two questions here:

**(1)** I don't really understand at all how this will affect **files shared with me by other people**.
This is my usual workflow:
- I have created a Gdrive folder (like [this one](https://drive.google.com/drive/folders/19GUp-ukmLEoEbu17ifPCnI60FhBJeX8i)) which I share with a couple of my clients' Google accounts, so they both can edit files inside the folder (basically, they upload and rename images, pdf and audio/video files). They can't edit folder sharing properties, and as I set the folder content to be public, all uploaded files should be public (everybody can view, without a Google account). So this folder is basically a public files repository (intended to be linkable from any website).
- Then, I run a PyDrive2 python script to process all content inside that folder. Based on file names/ids, I create the text and appropriate links to these files inside my clients' web page (an html file which I generate and upload to my server using the same python script).
My script works based on the public folder id, and then loops through file ids inside that folder.
I wonder if these ids are supposed to somehow change, or the announced changes do not affect api at all (just the public way of linking the files).
I mean ... if the ids change, I assume the links will change (so images embedded in the webpage will not be visible anymore).
But will the api still provide the updated ids to current PyDrive2 scripts? (so that it will be enough with re-running the script to update the public links in my webpage?).
Or perhaps that announced new "_**resource key**_" means **we will need to somehow modify PyDrive2 and/or our scripts** to use kinda double-id system in the future?
- BTW, not a PyDrive2 question, but I ask just in case anyone knows: In the above scenario, where my clients create and own the files, but they upload them to a public folder which is under my control ... who is the user which can actually decide to apply or not to apply the security update?
As far as I can tell, my clients cannot avoid the files to be public-visible when they decide to upload them to my public folder (they just can change my own permission: by default I can also edit those files). But I wonder if this security update will change that behaviour somehow.

**(2)** Regarding **my own files (those created and shared by me**, not by my clients):
The [above link FAQ](https://support.google.com/drive/answer/10729743#search) say I can find them using some Gdrive query tags (`is:security_update_applied` and `is:security_update_removed`).
Is it actually possible to somehow **use PyDrive2 to change the security update?**
Perhaps it is something which depends on a tag that can be changed through the api.

Thanks

Guía de contribución

Abrir la guía de contribución

Línea de trabajo

Start with the linked Google Drive security update and its FAQ, then inspect PyDrive2's API documentation and relevant wrapper entry points for file links and permissions. Done means clearly documenting whether resource keys or security-update controls affect PyDrive2 users and identifying any concrete API support gap; the issue names no files or tests.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
python
Área
api, security
Tipo de issue
Documentación
Dificultad
4/5
Tiempo estimado
3-5 días
Estado de actividad
Estancado
Claridad
Necesita aclaración
Aptitud para principiantes
20/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.