Project

General

Profile

Actions

Task #3299

closed

Google Drive and One Drive auth tokens

Added by Florian Effenberger over 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
High
Target version:
Team - Q2/2021
Start date:
2021-02-09
Due date:
2021-06-02
% Done:

100%


Description

Seems there are issues with accessing files on Google Drive and Microsoft One Drive, see

https://bugs.documentfoundation.org/show_bug.cgi?id=101630#c61
https://bugs.documentfoundation.org/show_bug.cgi?id=101630#c64

for the details. The solution seems to be both a technical and an administrative one.

We likely need accounts with both of the services and then file some paperwork.

Cloph, can you let us know where we have official accounts?
I think only at Google (the info@tdf one?), but I am not sure.

Xisco, with the account information at hand, can you chase what we have to do, prepare the technical bits and hand back to me for the paperwork?


Files

onedrive_wip.png (211 KB) onedrive_wip.png Christian Lohmaier, 2020-12-06 21:13
Actions #1

Updated by Florian Effenberger over 4 years ago

First estimate from Cloph is that this is not just related to paperwork/getting keys, but to our approach about on connecting to these services, that might need complete reimplementation (libcmis). He will investigate further and report back.

Actions #2

Updated by Christian Lohmaier about 4 years ago

for google It's not a problem with the keys, but rather how libcmis is handling the login procedures https://github.com/tdf/libcmis/issues/22 needs to be fixed, and it should work from within LO

Actions #3

Updated by Christian Lohmaier about 4 years ago

For microsoft onedrive the reason is not bad auth-tokens, but using obsolete (and now disabled, non-fuctional) API.
Migration seems straightforward enough that I can handle, but requires changes to both libcmis (that deals with the filebrowsing aspect) as well as LibreOffice (that defines the ouath enpoints/scopes to use)
https://docs.microsoft.com/en-us/onedrive/developer/rest-api/concepts/migrating-from-live-sdk

Only "issue" with the API-keys uses is that it's called "LibreOfficeDev" in the dialog to confirm the requested access to onedrive files, so changed the name and at the same time added the magic to have the domain verified using https://www.documentfoundation.org/.well-known/microsoft-identity-association.json

Also with the "open the link in the browser and copy the result back to the connect-to-server window" there really is no need to ask the user for the username/password for the onedrive account, LO cannot make use of it to login anymore.

Actions #4

Updated by Christian Lohmaier almost 4 years ago

  • Target version changed from Q3/2020 to Q4/2020

plan is to have the onedrive integration fixed with the 7.1 rc/in 7.1.0

Actions #5

Updated by Christian Lohmaier almost 4 years ago

wip - unfortunately not as strightforward/minimal changes as hoped, nevertheless basic functionality working again for onedrive. Opening/Saving files should be ready in time for rc1.

Actions #6

Updated by Florian Effenberger almost 4 years ago

  • Priority changed from Normal to High
  • Target version changed from Q4/2020 to Q1/2021
Actions #7

Updated by Christian Lohmaier almost 4 years ago

  • Due date set to 2021-03-14
  • Start date set to 2021-02-09

aim to have in in 7.1.2 for gdrive

Actions #8

Updated by Christian Lohmaier almost 4 years ago

  • % Done changed from 40 to 70

slight roadblocks for gdrive - the not-restricted scope that doesn't require extensive vetting of an application (drive.file) doesn't have a root folder to query, and there's no simple way to share random files with LibreOffice for editing at the moment. So the fix as in this scope will only work for files created/stored with LibreOffice itself.
Acessing other files not associated with LibreOffice would require either restricted access and a lengthy verification process (and proper storage of the refresh-token, I'm sure...) or integration with google picker https://developers.google.com/picker/ (a separate file selector - that is mainly meant for web applications though)…

Actions #9

Updated by Christian Lohmaier over 3 years ago

  • Due date changed from 2021-03-14 to 2021-04-25

adding google picker in a webapp to handle access to the files seems like a "von Hinten durch die Brust ins Auge" solution (overly complex using intermediate hops), so the better approach seems to go through the validation procedure.
But for that to have a chance to pass, we need to

a) properly store the refresh token (e.g. in the master-password locked pw-store that LO already has)
b) streamline the login procedure using the local listener instead of the copy'n'paste manual way

Both those changes will have benefits for both the onedrive as well as the gdrive integration, so the plan now is to start with the virtual/"fake" root folder for the drive.file access that cannot browse/is limited to the files the user did create with the app), and implement the above mentioned refresh-token/login improvements for 7.1.3 and then apply for the restricted scope validation.
Adjust due date for 7.1.3 rc2 accordingly

Actions #10

Updated by Florian Effenberger over 3 years ago

  • Target version changed from Q1/2021 to Q2/2021
Actions #11

Updated by Florian Effenberger over 3 years ago

  • Due date changed from 2021-04-25 to 2021-06-02
Actions #12

Updated by Christian Lohmaier over 3 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 70 to 100

Setting this one to resolved as the main functionality is there, what's remaining is UI cleanup (Repo-setup dialog should not ask for username and password, but rather just for a local label to use for the entry), and for better convenience listen on local port for the authentication code. The latter is not that important anymore, since the refresh-tokens are now stored and those are long lived, so the user only has to do the Copy-link-to-webbrowser-and-copy-code-back-to-LO once on initial creation and after a couple months once the refresh token expires.
And maybe LO can then apply for restricted scope access to be able to access all files on the drive, not just the files created with LO

  • to allow storing of the refresh token, you should enable persistent storage of credentials in Tools|Options → LO → Security → [x] allow persistent storage and [x] protect with master password. With that LO can store the refresh-token to use for further requests, and you only have to provide the master password.
  • With the persistent storage enabled, and trying to setup the connection for the first time, LO will ask for the masterpassword to look for an existing refresh token, on first setup there obviously won't be one so it will go to the login procedure: Copy'n'paste the link to your browser, grant LibreOffice the access to files → You will get an access token that you copy back to the LibreOffice dialog. LibreOffice will then ask once more for the masterpassword to store the refresh token obtained using the access-token.

Also important: LO is not verified to use restricted scopes yet, so it can only use drive.file scope, meaning when accessing GDrive from LO you'll only see the files that you created with LibreOffice, other files will not be accessible (you will however be able to see the files created with LO in e.g. in your gdrive in browser)

Actions #13

Updated by Florian Effenberger over 3 years ago

  • Status changed from Resolved to Closed
Actions #14

Updated by Xisco Fauli Tarazona over 3 years ago

Hi Cloph,
Should it be added to the release notes? < https://wiki.documentfoundation.org/ReleaseNotes/7.2 >

Actions

Also available in: Atom PDF