Update Google Drive Libraries

[TechplexEngineer]

Hello, thanks for open sourcing this project!

I'm attempting to get it running on a rpi4

When attempting to bring up the google drive connection I'm getting this error:

can2drive’s purpose is to store scans on Google Drive, so please

Error idpiframe_initialization_failed: You have created a new client application that uses libraries for user authentication or authorization that will soon be deprecated. New clients must use the new libraries instead; existing clients must also migrate before these libraries are deprecated. See the [Migration Guide](https://developers.google.com/identity/gsi/web/guides/gis-migration) for more information.

[stapelberg]

Thanks for the report!

Indeed, when I create a new OAuth Client ID, I also get the same error message.

I found https://developers.google.com/identity/oauth2/web/guides/migration-to-gis#gis-popup-ux, but it doesn’t work for me for some reason I have yet to figure out… The popup dialog appears, but after logging in and granting access, nothing seems to happen: no error in the JavaScript developer tools, no requests arriving at the server.

I’ll take another look tomorrow.

[TechplexEngineer]

I'm not sure of all the javascript features you are using. I started investigating and saw this quickstart which seems to not need any javascript to get a list of files and directories. Not sure if this would insulate the code from the everchanging javascript ecosystem. https://developers.google.com/drive/api/quickstart/go

[stapelberg]

The problem isn’t the Drive API itself, which we already use from Go.

The problem is the “sign in to google” functionality, which we need to get an access token to then access the Drive API from Go. This needs to remain JavaScript.

[TechplexEngineer]

Sorry, maybe I'm missing something here, but it seems the example above would enable a redirect based oauth flow so no javascript is needed. The sample code generates a URL which when loaded in a browser presents the Google login screen. Once a successful login has occurred, the url redirects back to the provided redirect_url.
This may present problems based on the limitations google places on redirect_url, but one can fall back to copying the generated code in the URL into the app.

[stapelberg]

I pushed a branch with how far I got: https://github.com/stapelberg/scan2drive/commits/oauth — feel free to check it out, replace the hard-coded http://localhost:7120 everywhere and give it a shot.

I found https://developers.google.com/identity/oauth2/web/guides/migration-to-gis#gis-popup-ux, but it doesn’t work for me for some reason I have yet to figure out… The popup dialog appears, but after logging in and granting access, nothing seems to happen: no error in the JavaScript developer tools, no requests arriving at the server.

The issue was that I had only configured http://localhost:7120 as “Authorised JavaScript origins” in my Client ID. I also needed to add http://localhost (without port) for the popup to work.

That said, we can’t use the implicit flow (with the popup), because it’s impossible to exchange an oauth2 token on the server side. For that, we need to use the redirect flow.

---

The “HTML API” (still using JavaScript in the background, just the developer doesn’t have to write JavaScript) only works for authN, not for authZ.

With the old library, authN and authZ were sort of mushed together, which was very convenient for tiny applications like this one.

With the new library, the idea seems to be that authN is the first step, and the app only does authZ where needed (e.g. when it actually wants to save a file), with granular fallback in case the user decides to grant only a subset of scopes. This is a good model for larger apps, but rather complicated for scan2drive, so I’m not sure it’s worth trying to implement that. The only advantage we would get is that the consent dialog would be a little more clear (no checkbox that the user can forget to tick).