2016-05-02 8 views
2

Wir haben eine Webanwendung, die in eine Reihe von Google APIs (Kalender, Kontakte, Laufwerke) integriert ist. Wir haben ein Integrationspanel, wo der Benutzer selektiv jede Integration on überprüfen kann. Wenn eine neue Integration aktiviert ist, speichern wir das neue Refresh-Token, das Google zurückgibt, und markieren das alte als inactive. Großartig bis jetzt.Google API-Aktualisierungstoken, die die Anforderungen für inkrementelle Bereiche nicht erfüllen

Das Problem ist, wenn wir einen neuen Bereich (inkrementell) anfordern, scheint Google den Bereich korrekt dem Benutzer hinzuzufügen (wenn wir freigegebene Bereiche aus dem Frontend überprüfen, zeigt es die richtige Liste), aber wenn wir Scopes aus dem überprüfen Zugriffs-Token wird nur das Profil und alles, was wir gerade angefordert haben, aufgelistet.

Wenn also jemand Kalender aktiviert, hat das Aktualisierungstoken "Profil" und "Kalender", aber wenn sie dann Laufwerk aktivieren, hat das neue Aktualisierungstoken nur "Profil" und "Laufwerk", nicht "Kalender". Dies ist besonders für unseren Google Drive-Mitarbeiter problematisch, da dadurch eine große Anzahl von Fehlern generiert wird, da versucht wird, ein Benutzerlaufwerk mit einem gültigen Aktualisierungs-Token, aber ungültigen Bereichen zu erstellen.

Im Backend verwende ich die setIncludeGrantedScopes(true) Methode, bevor ich die code einlöse, und soweit ich weiß, tut das Frontend, was es sollte (es scheint die erwarteten Bereiche zu haben), aber die Aktualisierung Token ist nicht inklusive.

Tipps/Tricks/Fehler/etc?

Antwort

1

Also, es stellt sich heraus, dass dies eine ziemlich einfache Lösung war, wurde aber nur an einer Stelle dokumentiert: Wenn das Front-End einen zusätzlichen Umfang anfordert, muss er auch alle aktuellen Bereiche senden nach oben.

Andernfalls führt das zurückgegebene Aktualisierungstoken nur zu den Bereichen, die in der Gewährungsanforderung enthalten sind, während die App schrittweise Bereiche wie erwartet erhält.