Google Calendar - update für "neue" GoogleAPI

[psilo]

nach auf stand der alten impl: das summary ist meine email-addresse, bei google steht dort aber mein klarname als kalendername (was früher m.E. auch gegangen ist): Unbenannt.PNG
Testen schaffe ich erst am Abend, muss heute früh ins Büro..

[smai]

Ist nun implementiert und committed, bitte testen.

Übrigens: Mit IPv6-Adressen funktioniert der Workaround per nip.io nicht, dort weiss ich keine Lösung. Dürfte aber auch eher selten sein im Heimnetz.

[smai]

irgendwie war der Kalendername den ich angeben musste jetzt meine E-Mail und nicht mehr der Name den ich in Google unter "Meine Kalender" sehe ?!

Das verwirrt mich, weil dies eigentlich früher so war. In meiner Version müsste es der Anzeigename sein.

Für das IP-Problem habe ich nun übrigens eine Lösung:
Die SV erkennt, wenn sie per IP aufgerufen wird. In diesem Fall wird der Redirect URI ein .nip.io angehängt. Nun kommt das Redirect, die SV erkennt dass da ein nip.io steht und macht ihrerseits ein Redirect zur IP.
Dies habe ich so getestet und funktioniert. Ich hatte aber noch keine Zeit, dies sauber zu implementieren.
Für die Benutzer ist der Ablauf damit wie in meiner ersten Version, nur steht halt in der zu kopierenden Redirect URI ein nip.io.

Einziger Nachteil: Es entsteht natürlich eine Abhängigkeit von nip.io.
Nur haben die wohl eine bessere Erreichbarkei als smartvisu.de

[psilo]

smai mit im ini file manuell eingetragenen Werten geht es jetzt. irgendwie war der Kalendername den ich angeben musste jetzt meine E-Mail und nicht mehr der Name den ich in Google unter "Meine Kalender" sehe ?!

[smai]

Nunja, gibt wohl schon etwas Traffic. Einige haben ja z.B. den Kalender unterhalb des Menüs, damit wird bei jedem Seitenwechsel ein Request ausgelöst.
Ausserdem ist man dann abhängig von der Verfügbarkeit eines einfachen Webspaces.
Aber mit smartvisu.de habe ich eh nichts zu tun, der Server gehört Apollo. Man müsste ihn anfragen.

Closed Source Software hat den Clientschlüssel wohl im Code eingebaut, auch wenn dieser mit gewissem Aufwand auch extrahiert werden kann.

[henfri]

Um die Einrichtung in der Developer Console zu umgehen, müsste das ganze googleV3.php auf smartvisu.de gehostet werden.

Warum nicht.
Viele (die allermeisten?) Anwendungen, die auf die Google Dienste zugreifen werden das so machen.
Alles andere hat nur eine geringe Reichweite.

Gruß,
Hendrik

[smai]

was ich mich eher frage: warum ging google v3 davor ohne diese geschichte

Weil man da diesen Schritt in google_1.php auf der Konsole ausgeführt und danach den Code manuell kopiert hat. Bdi der ganzen Aktion geht es eigentlich nur darum, zuerst due Benutzerzustimmung einzuholen um den temporären Code zu erhalten (wie in google_1.php) und danach mit diesem Codd das refresh_token abzuholen (zuvor google_2.php).

Die alte Variante war übrigens das was unter "Sonstiger Client" steht. selbst wenn ich die Daten in die .ini File selber eintrage, geht die neue Impl. dagegen nicht mehr

Das finde ich sehr überraschend. Wenn im config.ini die Felder calendar_google_client_id, calendar_google_client_secret und calendar_google_refresh_token mit den alten Werten gefüllt werden, müsste es meines Wissens funktionieren.

PS: habe gerade versucht anzufangen, beide files zu vergleichen. du hast aber ganz schön viel umgebaut aktuell.. bei manuellem eintragen der alten werte in das ini file, kriege ich auf der kommandozeile beim ausführen vom googleV3.php einen "Warning: fclose() expects parameter 1 to be resource, boolean given in /volume1/web/smartVISU/lib/functions.php on line 198"

Dies hat wahrscheinlich nichts mit meinen Anpassungen zu tun, sondern scheint ein alter Fehler beim Cache lesen zu sein. Ich werde den natürlich korrigieren, danke.

Ich habe den Code zwar ziemlich überarbeitet, der grundsätzlichen Ablauf ist aber unverändert. Dies primär mit dem Ziel, die Performance zu verbessern. Im Detail habe ich folgende Änderungen gemacht:

1. client_id, client_secret und refresh_token werden aus der Konfiguration gelesen.
2. Die Abfrage des access_tokens geschieht wie die anderen per file_get_contents anstatt per CURL (Zeilen 49 - 66). CURL ist nicht standardmässig integriert in PHP.
3. Das access_token wird in einem Cookie auf dem Client zwischengespeichert, damit dessen Abfrage nur einmal pro Stunde gemacht werden muss. (Zeile 70)
4. Die Kalender werden wie zuvor geschrieben Anhand des Namens anstelle der ID selektiert. Zudem werden diese gecached und nur neu gelesen, wenn einer davon noch nicht im Cache ist. (Zeilen 115 - 143)
5. Die events selbst werden hingegen nicht mehr auf dem Server gecached, damit Änderungen sofort sichtbar werden. Dafür werden sie auf dem Client gepuffert. Wenn man navigiert, werden auf dem Client sofort die gepufferten Events angezeigt und dann aktualisiert, wenn nach einer halben Sekunde oder so die aktuellen gelade sind. Dies ist gleich wie es auch bei den Daten vom Bus der Fall ist.
6. Allgemein werden in jeder Googleabfrage nur die benötigten Felder angefragt (URL-Parameter fields). Zusätzlich wird bei den Events das maximale Datum begrenzt auf dasjenige, des letzten noch anzuzeigenden Termins. Beispiel: Ich habe im Widget eingestellt, dass 10 Zeilen angezeigt werden sollen und dies aus zwei Kalendern. Sind nun im ersten Kalender bereits 10 oder mehr Events vorhanden, wird aus dem zweiten Kalender nur noch bis zum Datum des 10. Events gelesen. Alle späteren würden eh wieder rausfliegen.
7. Die Sortierung und Begrenzung auf die Msximalanzahl ist nicht mehr in googleV3.php implementiert sondern nutzt die Merhode des Elernobjekts aus calendar.php

Wäre es nicht eine Möglichkeit beide Probleme zu umgehen, indem man diesen Schritt unter SmartVisu.de hostet?

Dies hatte ich mir auch überlegt. Damit könnte zwar das IP-Problem umgangen werden. Der Clientschlüssel wäre aber trotzdem notwendig, weil dieser bei der eigentlichen Kalenderabfrage gebraucht wird.
Um die Einrichtung in der Developer Console zu umgehen, müsste das ganze googleV3.php auf smartvisu.de gehostet werden.

Ich werde heute Abend noch testen, ob ich bei Verwendung einer IP einfach als redirect_url den entsprechenden nip.io Eintrag angeben kann. Damit müsste der User die Config-Seite selbst nicht per nip.io aufrufen. Ich weiss aber noch nicht, ob Google einen anderen Host als den Origin zulässt beim Redirect.

[henfri]

Hallo,

Weil die smartVISU Open Source ist.

...
Und dies funktioniert anscheinend nicht mit Webapplikationen, welche per IP aufgerufen werden.

Wäre es nicht eine Möglichkeit beide Probleme zu umgehen, indem man diesen Schritt unter SmartVisu.de hostet?
Ich habe schon anderen Anwendungen (Mail-Client z.B.) Zugriff so erteilt.
Der SV würde ich da auch trauen.


Gruß,
Hendrik

[psilo]

smai was ich mich eher frage: warum ging google v3 davor ohne diese geschichte

Die alte Variante war übrigens das was unter "Sonstiger Client" steht. selbst wenn ich die Daten in die .ini File selber eintrage, geht die neue Impl. dagegen nicht mehr

PS: habe gerade versucht anzufangen, beide files zu vergleichen. du hast aber ganz schön viel umgebaut aktuell.. bei manuellem eintragen der alten werte in das ini file, kriege ich auf der kommandozeile beim ausführen vom googleV3.php einen "Warning: fclose() expects parameter 1 to be resource, boolean given in /volume1/web/smartVISU/lib/functions.php on line 198"

[smai]

Warum braucht man eigentlich die Dev Console? Bei anderen Applikationen geht es doch auch ohne?

Weil die smartVISU Open Source ist.

Um auf Benutzerdaten bei Google zugreifen zu können, braucht es eine Client-ID und ein Client Secret (in Deutsch Clientschlüssel genannt).
Und dieser Schlüssel ist geheim zu halten, denn wenn jemand damit Unfug treibt, wird dieser (oder im schlimmsten Fall der zugehörige Google Account) gesperrt.

Aber selbst wenn ich nun meinen Schlüssel einbauen würde, nützt das noch nichts. Denn damit eine Applikation Benutzerdaten lesen kann, muss der Benutzer dies erlauben (eigentlich logisch). Und dies funktioniert anscheinend nicht mit Webapplikationen, welche per IP aufgerufen werden.

[smai]

Also, obwohl Google bei Script Quellen die Eingabe einer lokale IP zulässt, verweigern sie danach trotzdem die Autorisierung.
Bisher habe ich einzig die Lösung gefunden, dass du die Config Page z.B. per http://192.168.178.100.nip.io aufrufst. Dies ist ein Dienst, der jede IP als Host Name mapped.

[henfri]

@smai: Danke für deinen Einsatz!!

Warum braucht man eigentlich die Dev Console? Bei anderen Applikationen geht es doch auch ohne?

[psilo]

nein, nur vom typ "Sonstige"

[smai]

Google treibt mich noch in den Wahnsinn

Schritt 9 gibt es bei mir in der Google Developer Console immer noch nicht.

Hast du evtl. im selben Projekt bereits Zugangsdaten vom Typ Webserver? Dann sieht der Dialog etwas anders aus, weil er dich fragt, ob du diese verwenden willst: screenshot.png


Du kannst dann entweder Neue Client-ID erstellen klicken und es geht weiter wie in der Anleitung. Oder die wählst unten die bestehende Client-ID, muss dann aber den Rest von Hand machen.

Aber das eigentliche Problem mit lokalen IPs löst dies trotzdem nicht. Ich werde das am Abend mal testen mit IP.

[psilo]

keine besserung - hier mal mit requestdaten - leicht zensiert um meine keys..:

Unbenannt-1.png