Google Calendar - update für "neue" GoogleAPI

[wvhn]

So. Hier mal ein erster Schuss. In meinen Tests hat die Authorisierung sowohl bei einem Domain-Namen als auch bei der internen IP-Adresse des smartVISU-Servers funktioniert. Die beiden angehängten Dateien müssen anstelle der ./lib/base/config.js und ./pages/base/config.google.html eingespielt werden.

Kannst Du das mal testen? Es sollte eigentlich ausreichen, die bereits heruntergeladene JSON-Datei mit den Credentials zu laden und dann auf "Authorisieren" zu klicken.

Wenn das klappt, werde ich noch den etwas geänderten Ablauf auf der Google Developer Seite in die Schritt-für-Schritt-Anleitung einarbeiten.


Gruß
Wolfram

[himself]

Funktioniert! Vielen Dank!

[wvhn]

Die geänderte Version ist jetzt im develop branch.

Gruß
Wolfram

[himself]

Keine Ahnung wieso aber es geht wieder nicht. Ausgabe der Konsole:

XHRGET http://192.168.178.27/smartvisu_3_5/lib/calendar/service/googleV3.php?count=5&calendar=
[HTTP/1 500 smartVISU Service Error 206ms]
   
GET http://192.168.178.27/smartvisu_3_5/lib/calendar/service/googleV3.php?count=5&calendar=
Status 500 smartVISU Service Error
VersionHTTP/1
Übertragen312 B (131 B Größe)
Referrer Policystrict-origin-when-cross-origin
DNS-AuflösungSystem​

Ich kann das nicht wirklich interpretieren, bzw. sehe nicht wo hier ein Fehler wäre.

[wvhn]

Ich hatte meinen Server ein paar Tage ausgeschaltet und musste nach dem Hochfahren des Servers die Autorisierung neu machen. Nicht komplett neu, aber mit den bestehenden Credentials nochmal auf "Autorisieren" klicken und das Google-Popup durchmachen. Allerdings bekam ich beim Starten der Visu das Fehlerdreieck angezeigt und einen entsprechenden Fehler, dass kein Autorisierungs-Token bezogen werden konnte. Jetzt habe ich den Server mit dem Kalender täglich unter Beobachtung und schaue, was man ggfls gegen das Ablaufen des Autorisierungscodes tun kann.
Probier mal, ob eine neue Autorisierung das Problem löst.

Du kannst den Service mal direkt mit debug-Flag aufrufen:

http://192.168.178.27/smartvisu_3_5/lib/calendar/service/googleV3.php?debug=1

Evtl. werden dort erweiterte Infos angezeigt. Bitte prüfe auch die error.log des Webservers.

Gruß
Wolfram

[himself]

Hi Wolfram,

neu Autorisieren bringt bei mir keinen Erfolg.

SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data

/************************************************** *****************************
data
--------------------------------------------------------------------------------
Array
(
[0] => Array
(
[title] => Calendar: Google
[text] => HTTP request failed! HTTP/1.1 400 Bad Request
<br><br>Unable to retrieve access token.
)

)

************************************************** *****************************/

[{"title":"Calendar: Google","text":"HTTP request failed! HTTP\/1.1 400 Bad Request\r\n<br><br>Unable to retrieve access token."}]​

error.log:

[Wed Apr 09 00:00:02.221737 2025] [core:notice] [pid 182] AH00094: Command line: '/usr/sbin/apache2'
[Wed Apr 09 21:41:43.112246 2025] [php:notice] [pid 42630] [client 192.168.178.231:52282] PHP Notice:  file_get_contents(): Content-type not specified assuming application/x-www-form-urlencoded in /var/www/html/smartvisu_3_5/lib/calendar/service/googleV3.php on line 64
[Wed Apr 09 21:41:43.193056 2025] [php:warn] [pid 42630] [client 192.168.178.231:52282] PHP Warning:  file_get_contents(https://accounts.google.com/o/oauth2/token): Failed to open stream: HTTP request failed! HTTP/1.1 400 Bad Request\r\n in /var/www/html/smartvisu_3_5/lib/calendar/service/googleV3.php on line 64

​

[wvhn]

Hast Du nach dem Autorisieren die Einstellungen der Konfiguration abgespeichert?

Gruß
Wolfram

[himself]

Hi, bin mir ziemlich sicher das ja. Habe gestern noch mal die beiden Dateien kopiert und dann ging es wieder. Kann also sein dass ich da selber was vermurkst habe.

[wvhn]

Laut Google gilt das Refresh Token nur 7 Tage:

Für ein Google Cloud-Plattformprojekt mit einem OAuth-Zustimmungsbildschirm, der für einen externen Nutzertyp konfiguriert ist, und dem Veröffentlichungsstatus „Testen“ wird ein Aktualisierungstoken mit einer Gültigkeitsdauer von 7 Tagen ausgestellt,

Das würde bedeuten, dass smartVISU alle 7 Tage neu autorisiert werden muss. Ich kann nicht sagen, ob das schon immer so war und habe noch nicht herausgefunden, ob sich das ändern lässt. Gute Ideen sind hier willkommen!

Damit die Autorisierung einfacher wird, habe ich die ./pages/base/config.html nochmal geändert (Siehe Anhang): hier werden - falls vorhanden - die in der Konfiguration gespeicherten client_id und client_secret im Formular schon vorbefüllt, so das sich die Suche nach der json-Datei erübrigt und die Autorisierung schneller geht.

Für Tests bin ich dankbar.

Gruß
Wolfram

[Sipple]

Hi Wolfram

Alle OAuth Endpunkte die ich kenne (das sind inzwischen einige) und die eine limitierte Gültigkeit des Tokens haben, liefern während des Prozesses die Gültigkeitsdauer des Tokens und ein "Refresh-Token", mit dem man vor Ablauf der Gültigkeit ein neues Token anfordern kann.
Will Google da tatsächlich, dass man das manuell neu authentifiziert?

[wvhn]

Moin Martin,

so ist es auch hier. Der Authentifizierungsprozess auf der Config-Seite erhält von Google zunächst einen Autorisierungs-Code, der in ein Refresh-Token getauscht wird. Dieses wird in der config.ini abgespeichert.

Mittels des Refresh-Tokens erhält das Kalender-Skript ein Autorisierungs-Token, das 1 Stunde gültig ist. Dies wird als Cookie gespeichert und über das Refresh-Token erneuert, sobald es abläuft oder das Cookie gelöscht wird. Offenbar ist das Refresh-Token selbst aber nur 7 Tage gültig.

Wer einen bezahlten Google Cloud-Account hat und die Freigabe deshalb nicht für den "externen Nutzertyp" machen muss, profitiert wahrscheinlich von längeren Verfallsfristen. Das kann ich allerdings nicht testen.

Am Wochenende läuft mein Refresh-Token ab. Dann schaue ich mal, ob ich noch einen anderen Ansatz finde.

Gruß
Wolfram

[Sipple]

D.h., man bekommt ein einziges Refresh-Token, das man 7 Tage lang für die Autorisierung verwendet, dann läuft es ab und man muss manuell eingreifen? Ungewöhnlich.
Ich kenne das nur so, dass man jedes mal, wenn man ein Refresh-Token verwendet, in der Antwort ein neues bekommt. Oder zumindest so ähnlich.
Ich habe hier auch Fälle, wo ich erst gar kein Refresh mache und den Autorisierungsprozess immer neu anstoße (mit username+passwort). Da spart man sich den ganzen Refresh Code und es geht auch so. So einfach geht das bei Google aber wohl nicht.

[himself]

Hi Wolfram,

ich habe die neue Config getestet. Die Werte stehen zwar drin, aber ich muss trotzdem die Datei auswählen um den Button zu "aktivieren" also klickbar zu machen.
Wo kann ich denn sehen wann mein Token abläuft?

[wvhn]

Ich habe das jetzt nochmal ausführlich mit ChatGPT diskutiert. Seines Wissens nach gibt es keinen Weg zur Umgehung der Beschränkung. Ich habe in der Dokumentation und auch in den einschlägigen Foren ebenfalls nichts dazu gefunden.

Man kann lediglich die Bedingungen für die Testnutzung ändern - dann wird die Lebensdauer des Refresh-Tokens unbegrenzt:

• im OAuth-Zustimmungsbildschirm die "App veröffentlichen". Dazu müssen die autorisierten Javascript-Quellen auf https umgestellt und dann auch per https aufgerufen werden. Wer seine smartVISU über das Internet per https erreichbar gemacht hat, sollte damit keine Probleme haben. Um die Visu im hauseigenen Netz ohne Reverse Proxy per https aufzurufen, braucht man aber TLS-Zertifikate für den Websocketserver von shNG (siehe hier).
  Nachteil: das Projekt ist dann öffentlich für jeden Google-Nutzer sichtbar. D.h. der Zugang muss gut abgesichert sein.
• ODER den Nutzertyp auf interne Nutzer stellen. Dazu braucht man allerdings einen kostenpflichtigen Google Workspace-Account. Wer den sowieso hat, ist fein raus.

Ich versuche jetzt mal, das Generieren eines neuen Refresh-Tokens komfortabler zu machen - möglichst gleich aus der Fehlermeldung heraus. Erster Schritt dazu ist die oben angehängte config.html. Sie sorgt dafür, dass man schnell wieder auf dem Zustimmungs-Popup von Google landet und nicht erst die Credentials suchen muss.

Gruß
Wolfram

[wvhn]

himself Sorry, ich habe Deine Frage erst jetzt gesehen, weil ich wohl parallel die Zusamenfassung geschrieben habe.

Leider hast Du recht, dass die Seite - wenn Du mit IP-Adresse autorisierst - nicht so funktioniert, wie mit einem Domain-Namen. Ich arbeite daran.
Du musst die json-Datei aber nicht neu laden. Es reicht, in das Eingabefeld für client_id zu klicken und danach auf "Autorisieren" zu klicken.

Das Ablaufdatum kannst Du mit einem Cookie-Manager auslesen - in Firefox z.B. "Cookie Quick Manager". Ich kann aber mal sehen, wo ich das in der Visu sinnvoll anzeigen kann.

Gruß
Wolfram

EDIT: es muss nur das Feld für client_id angeklickt werden -> client_secret gelöscht.