Partial compatibility with Google security update 2021

[agrenott]

Google Drive added a new "resourceKey" attribute required to access documents shared by links. This resourceKey must be passed through HTTP header, aside with the document ID. resourceKey can be retrieved from a previous list operation on containing folder. Partial implementation; only for basic methods: GetContentFile, GetContentIOBuffer and FetchMetadata.

Ref.

• Google Drive security update 2021- questions, how does it affect PyDrive2, how to deal with it #129
• https://developers.google.com/drive/api/guides/resource-keys
• https://issuetracker.google.com/issues/312938132

Few remarks:

• As the unit tests of PyDrive2 rely on actual Google Drive API usage, I've used an existing public document which I know is impacted. It could be smaller though...
• I only implemented the basic read operations because they're easy to test with a read-only public file. I'm not sure we can create a file requiring resourceKey using the API (as I understand it's for files shared by link only), and don't see how we can simply/safely use a publicly writable shared document. And let's be honest, I only need one of them :)
• At a first glance I feel GetContentFile could be refactored to rely on GetContentIOBuffer, avoiding some code duplication

[shcheklein]

thanks @agrenott ! Please check linter / tests failures. Also, I don't think we can rely on an external file in tests. We need to do some research and create via API, if not possible, let me know how I can create a file / share a link manually. Let's create it in some account that is controlled via the same account that we use for tests.

[agrenott]

Hi @shcheklein ,
I've fixed the linter issue. I'm a bit puzzled by the failing test, as it's specific to python 3.10 and doesn't seem directly related to my change. Let's see if it happens on next run.

Concerning the unit tests, sadly I can't find a way to create a new file impacted by the resourceKey requirement (neither via API nor manually in Drive UI). Googling a bit, I think it has only been used as a work-around on old files (pre-2021?) which were allocated a not-so-random ID.
rclone's source code seems to point into that direction as well: https://github.com/rclone/rclone/blob/master/backend/drive/drive.go#L659

So I don't have much better idea than relying on an existing public impacted file if we want to test those relying on the E2E usage of GDrive. Alternative would be to mock GDrive for those tests.

[shcheklein]

thanks @agrenott !

Alternative would be to mock GDrive for those tests.

let's mock it then and put an actual file for a reference and some code to test it if needed

as it's specific to python 3.10 and doesn't seem directly related to my change. Let's see if it happens on next run.

I'll take a look and let you know. Sometimes it happens since we run too many API calls in parallel.

[agrenott]

Mock implemented, and marked the real tests with as "manual", hope it's enough to disable them by default.

[shcheklein]

thanks @agrenott ! I've updated the GH actions a bit (bumped the versions). Tests pass. I've reviewed now the code itself and put some questions / comments - PTAL.

[agrenott]

Hi @shcheklein, are you fine merging this PR in its current state or do you expect more changes?

[shcheklein]

@agrenott I haven't had time to do the final review yet. Let me get back to it soon. I'll let you know. AFAIR it should be fine, but let me do the final pass.

[shcheklein]

@agrenott PTAL - just a few minor comments

[shcheklein]

@agrenott merged and released. Thanks 🙏

[agrenott]

You're welcome! It's nice to be able to contribute to some project I rely upon.