Google Drive Backup Support

[bobveringa]

Ik gebruik DSMR-reader nu zelf al een paar maanden en het is geweldig. Ik zou zelf graag google drive support toevoegen. De afgelopen paar dagen heb ik gewerkt aan een implementatie van google drive API om te kijken of het mogelijk is om toe te voegen. Ik ben nu op het punt waarop ik testen kan gaan schrijven en het kan gaan toevoegen aan DSMR. Is Google Drive support iets waar je interesse in hebt om toe te voegen.

Ik zie ook dat je dropbox een eigen app hebt gemaakt binnen Django, wat zou de beste manier zijn om google drive support toe te voegen.

Ik ben redelijk nieuw met python, dit is voor mij een oefenproject om wat bekender te raken met de taal. Dus het is niet erg als er je er geen interesse in hebt.

[dennissiemensma]

Bedankt voor je voorstel. Ik heb zeker interesse in Google Drive, want meer keuze voor back-up is altijd goed. Als je wilt leren met Python dan kan ik je zeker wel op weg helpen. Ik kan je niet beloven of ik het zo 1-op-1 overneem, maar als je het beschikbaar stelt kan ik het misschien wel deels gebruiken en zet ik je uiteraard bij de credits.

Het is goed om te weten dat ik momenteel bezig ben met het deels herschrijven van dr Dropbox-sync, dus de dev-versie is het betere voorbeeld. Synchronisatie wordt nu bepaald door de bestands-hash en daarnaast heb ik het in een losse app gezet.

Wat betreft je vraag over hoe het toe te voegen. Ik denk dat je er doorgaans een losse app van kan maken. Eigenlijk zijn apps in Django bedoeld om alles los en portable te houden, maar binnen dit project is het meer splitsing van domein. Ik zou beginnen met het maken van een management command waarmee je makkelijk handmatig kan testen. Deze heb ik van de week toegevoegd voor Dropbox. Daarna kun je tests maken. In Python kun je heel makkelijk een hoop dingen mocken, maar dat heeft wel een leer-curve. Of mocken werkt is namelijk afhankelijk van hoe je een module in Python importeert en gebruikt (from x import y of import x.y). Voorbeeld voor dropbox tests hier. Het zijn niet de mooiste tests, maar je kunt een hoop scenario's (tot aan de API-call) testen.

[dennissiemensma]

Los van de code, is het afdoende om OAuth te doen via de webinterface voor Google Drive of moeten we, net als Dropbox, voor elke installatie een eigen App aanvragen bij Google?

[bobveringa]

Omdat ik zelf net erg bekend ben met python had ik de development versie al gebruikt om wat dingen op te doen. Ik ben ook niet bekend met Django, maar het moet denk ik niet al te moeilijk zijn om een app aan te maken.

Met betrekking tot OAuth, bij mijn huidige implementatie is het nodig om een app aan te maken en om Oauth te doen. Tenzij je een application published via google is dat denk ik ook de enige manier.

Daarnaast nog een vraag. Ik maak op dit moment gebruik van "Oauth 2.0 for TV and Limited Input Devices" https://developers.google.com/identity/protocols/OAuth2ForDevices. Omdat de ingebouwde methods in de client library allemaal blocking zijn.

Er moet helaas wel redelijk wat informatie opgeslagen worden, tussen de 7-8 velden met tokens, id’s en secrets enzovoort. Mijn huidige idee is om dit allemaal gewoon in een GoogleDriveSettings object op te slaan, en alleen de velden die nodig zijn aan de gebruiker te laten zien.

Is dat een goed idee, of is het beter om deze informatie ergens anders op te slaan?

[dennissiemensma]

Je kunt die inderdaad het beste in de settings opslaan, zoals je voorstelt. In de admin-interface kun je vrij makkelijk velden naar wens tonen of verbergen.

[bobveringa]

Ik heb zojuist de laatste tests geschreven voor de google drive integratie. Ik zou graag horen wat je er van vindt, en wat er eventueel aangepast zou moeten worden.

[dennissiemensma]

Goed bezig! Ik heb alleen even een diff in de browser bekeken met: https://github.com/dennissiemensma/dsmr-reader/compare/development...bover21:690-googledrive-support

Hier wat dingen die ik kan zien:

• authorization_url_view lijkt me een string die je het beste in de dsmrreader settings file kan bijhouden.

• De naam dsmr_gdrive kun je beter volledig uitschrijven voor de consistentie. Bijvoorbeeld dsmr_googledrive of dsmr_google_drive.

• Ik heb inhoudelijk geen kennis van de API of wat nodig is, maar ik zie wat custom http requests in dsmr_gdrive/gdrive/drive_api.py. Zitten die toevallig ook al in de client-library van Google voor Python? Want dan kun je die beter gebruiken. Zie: https://developers.google.com/drive/api/v3/quickstart/python

• Op sommige plekken staat een pass, die kan weg. Zodra er andere code of een multiline comment staat, is die niet meer nodig.

• In de services staat ergens een hardcoded lijstje van gdrive_settings.state == 0 etc. Dat kun je beter veranderen naar constanten zodat leesbaar is wat ze betekenen. Bijvoorbeeld in de dsmrreader settings.

• Qua tests ziet het er heel uitgebreid uit, maar het is te veel om nu even tussendoor te zeggen of dit allemaal afdoende is. Je kunt sowieso de code coverage lib gebruiken, mocht je die al niet gebruikt hebben.

• Heb je verder ook nog een beschrijving van de flow of hoe dit uitgeprobeerd kan worden?

Op een later moment kan ik er wat inhoudelijker naar kijken, maar gezien de hoeveelheid code heb ik daar aardig wat tijd voor nodig.

[bobveringa]

Bedankt voor je snelle reactie en de goede verbeter punten.

• ‘authorization_url_view’ is een functie die een ander veld ‘authorization_url’ klikbaar maakt binnen in de GoogleDriveSettings. Ik heb deze in de GoogleDriveSettings staan omdat, deze url wordt gereturned als je een access request naar google maakt, en de gebruiker hier op moet klikken.

• Ik heb een aantal expirmenten gedaan met de google client-library maar de authorization maakt hierbij gebruik van het lokaal hosten van een webpagina (er zijn ook andere mogelijkheden), waarna de gebruiker wordt gestuurd als de authenticatie voorbij is. Daarnaast is de call voor authenticatie blocking waardoor de rest van de backend functies niet zouden kunnen lopen. En alhoewel dit mogelijk te overzien is, vindt ik het persoonlijk fijner als backend calls niet blocking zijn. .
  Voor de authentactie heb ik daarom een implementatie gemaakt van een ander onderdeel genaamt ‘OAuth 2.0 for TV and Limited-Input Device Applications‘. . Het nadeel hieraan is echter dat met deze authenticatie eenmaal verkregen is het niet eenvoudig om de credentials die hieruit komen om te zetten in een GAuth object. Het is niet onmogelijk, en ik heb dit werkende gekregen met een test die ik had opgezet, maar deze was niet heel erg stabiel. . Een andere optie is PyDrive hierbij is het wel mogelijk om een eigen manier van authenicatie toe te passen. Maar dan is het gebruik van bestandsuploading nodig in het admin panel omdat, deze library gebruik maakt van het ‘credentials.json’ dat gedownload kan worden via de developer console. Naast dit bestand is het dan ook nodig om een bestand met verschillende settings specifiek voor PyDrive ergens bij te houden, en in mijn testen was dit niet helemaal een success in combinatie met Django. . Na al dezen mislukte testen, was het eenvoudiger om zelf een implementatie te maken van het google drive api dan gebruik te maken van al bestaande libraries. Maar ik denk met flink wat extra tijd dat het wel mogelijk moet zijn om ‘google client-library’ of ‘PyDrive’ werkende te krijgen, mocht dat een vereiste zijn.

• Ik programmeer in PyCharm en heb de code coverage tools daarvan gebruikt. De code coverage van zowel ‘services.py’ als ‘drive_api.py’ zou 100% moeten zijn. Maar ik denk dat er nog steeds wel een aantal verbeter punten zijn voor mijn tests. Dat is namelijk niet echt iets waar mijn opleiding veel tijd aan besteed.

• Helaas is het niet zo eenvoudig om google drive toe te voegen als het is om om dropbox toe te voegen. De simpelste manier om google drive toe te voegen is niet via de developer console, maar via de python quickstart tutorial. Omdat je op deze manier zo’n 12 stappen overslaat. Het nadeel is echter dat de naam van het project vaststaat door google.

Setup

• Ga naar ‘https://developers.google.com/drive/api/v3/quickstart/python’
• Alleen stap 1 is nodig, klik op Enable The Drive API, en kopieer de client_id en client_secret die hieruit komen.
• Ga naar de Google Drive Settings in het admin panel, en vul de client_id en client_secret in druk save
• Refresh de pagina, als het goed is zijn authorization url en user code nu ingevuld.
• Klik op de url en vul op de pagina de user code in. En geef alle verdere toestoeming. De scope van de permissions is ‘https://www.googleapis.com/auth/drive.file’ en de applicatie heeft alleen toegang tot bestanden en folders die door de applicatie worden geupload
• Google Drive is nu ingesteld

[dennissiemensma]

Bedankt voor je toelichting! Ik kijk er op termijn inhoudelijker naar.

[dennissiemensma]

Ik ben hier opnieuw mee bezig geweest. Ik steun je verzoek om ondersteuning te bieden voor Google Drive, alleen ga ik dan via externe tools doen.

De reden is dat een aanzienlijk deel van dit project bestaat uit code voor het backuppen en veiligstellen van de data. Hoewel dat natuurlijk erg belangrijk is, is het niet de kern van het project en ik merk dat ik hier het afgelopen jaar ontzettend veel tijd aan kwijt ben.

Daarom wil ik later dit jaar kijken naar alternatieven. Niet alleen voor GDrive, maar ook voor de Dropbox-support die ik al had.

Voor GDrive lijkt me dit een interessante tool: https://github.com/gdrive-org/gdrive

Concreet zou dat betekenen dat DSMR-reader alleen de backups maakt (of misschien verander ik dat ook nog naar een crontab-variant), en dat het sycnen van data naar een derde partij niet meer afhankelijk is van een implementatie binnen dit project.

[dennissiemensma]

Hetzelfde geldt voor MS OneDrive, waar ook al langere tijd een ticket (#528) is binnen dit project.

[bobveringa]

Dat is best een goed idee. Ik had zelf ook kort gekeken naar een implementatie voor OneDrive, maar in tegenstelling tot google heeft de API alleen blocking calls daarom heb ik daarvan af gezien. Met een externe service zou het niet uitmaken dat het opzetten van een backup service blocking is omdat het de belangrijke services dan niet stopt.

Is het eventueel een idee om in de API een call toe te voegen waarmee het backup path opgevraagd kan worden. Op deze manier is alleen maar een reference naar de API nodig om het path te vinden en maakt het voor de exterene service niet uit als de locatie veranderd.

[dennissiemensma]

Ik denk dat het backup-pad gewoon standaard blijft. Maar het kan ook zo zijn dat die buiten de applicatie-map gaat, als ik backuppen ook via de crontab wil doen.

Deze wijzigingen zullen sowieso pas in een DSMR-reader v3.x komen, omdat ze backwards incompatible zijn en ik dan ook grote wijzigingen kan doorvoeren. Als er dan de noodzaak is om het pad op te vragen, komt dat er wel in.

[dennissiemensma]

Ik heb besloten dit verder niet op te pakken of te integreren binnen dit project. Wat meer uitleg staat in: https://github.com/dennissiemensma/dsmr-reader/issues/528#issuecomment-592174552