Zugriff auf Google API neue OAuth 2.0

[Mavarik]

Ja das habe ich auch gelesen...

Ich habe das problem zurückgestellt, weil ich das seht unpraktisch finde...

Ich gehe das Problem nochmal Ende des Jahres an!


Mavarik

[vagtler]

Mittlerweile gibt es eine neue Version der o.g. Komponente. Aus der Release-Info:

Zitat:

• It uses most recent Google Calendar API v.3. Previous version of our component used API v.2, which is now officially deprecated
• Includes full support for OAuth 2.0 authorization (including Google 2-step verification). Previous version of the component used ClienLogin, which is now also deprecated and is not recommended by Google. In many cases ClientLogin simply does not work (such as 2-step verification or SAML)

[sh17]

Nutzt inzwischen jemand

Google Calendar Delphi Component

oder

TMS Cloud Pack

und kann diesbezüglich einen Kommentar zur Nutzbarkeit sagen.

Ich tendiere momentan vor der Variante "selbst machen" noch zu 1. Wobei ich die Umsetzung von OAuth 2.0 schon mal probehalber programmiert habe.

[vagtler]

Zitat von sh17:

Nutzt inzwischen jemand

Google Calendar Delphi Component [...]

???

http://www.delphipraxis.net/1171048-post7.html

[mjustin]

Zitat von vagtler:

Für die (Termin-)Synchronisation mit Google verwenden wir erfolgreich die Komponenten von http://www.sync-components.com/googl...oogle-calendar

Vielleicht wäre das eine denkbare Alternative für Dich.

Die Demo habe ich mir gerade mal angesehen, man wird um eine broswerbasierte Anmeldung gebeten. Dann muss man aus einem Browserfenster einen Key mittels Copy & Paste in die Delphi Anwendung hinein kopieren. Ich nehme an, das kann man nicht umgehen...

Schaue mir OpenID mal im Android Bereich an, ob es dort eleganter geht.

[sh17]

Hätte doch einen eigenen Thread machen sollen. Ich meinte, ob jemand eine der Komponenten generell empfehlen kann, oder ob es Probleme gibt. Die TMS ist ja wesentlich günstiger und hat noch andere Schnittstellen, obwohl im Google-Kalender-Bereich ist sie nicht ganz so komplex.

Wg dem Key. Also ich schätz mal das ist nur in der Demo so gemacht. Ich habe es in meiner Probeimplementierung so gelöst, das ich den Zugriff auf die API über eine TWebBrowser-Fenster durchführe. Den Key kann man sich von Google als HTML-Titel zurückgeben lassen und kann ihn damit aus dem Browser-Fenster einfach auslesen. Muss der Anwender nichts kopieren.

[mjustin]

Zitat von sh17:

Wg dem Key. Also ich schätz mal das ist nur in der Demo so gemacht. Ich habe es in meiner Probeimplementierung so gelöst, das ich den Zugriff auf die API über eine TWebBrowser-Fenster durchführe. Den Key kann man sich von Google als HTML-Titel zurückgeben lassen und kann ihn damit aus dem Browser-Fenster einfach auslesen. Muss der Anwender nichts kopieren.

Ok, aber einen Browser braucht das Delphi Programm also für diesen Trick auf jeden Fall (wenn auch intern und unsichtbar). Aber wie ich jetzt in meinem Google Account sehe, wird das Demo Programm als berechtigter Benutzer permanent gespeichert unter der ID "Aston ToDo" hat es fortan Rechte auf meinen Google Calendar. Bei jedem weiteren Start ist die Berechtigung also schon vorhanden. Nach KISS würde ich die Delphi Anwendung dann ohne Webbrowser bauen, der Trick mit dem internen TWebbrowser Fenster könnte ja mal versperrt werden, während der normale (externe) Browser weiter funktioniert.

[sh17]

Ja, die Rechte müsstest Du der Demo (der ID) wieder entziehen.

Generell müsste man den Dialog zur Eingabe des Passwortes ja nur nachbilden. Dann sollte es auch ohne Browser klappen. Wenn das schon jemand hat, wäre ich durchaus daran interessiert.

[mjustin]

Zitat von sh17:

Generell müsste man den Dialog zur Eingabe des Passwortes ja nur nachbilden. Dann sollte es auch ohne Browser klappen.

Damit werden natürlich alle Sicherheitsvorteile unterlaufen, die eine browserbasierte Anmeldung mit OpenID hat:

Zitat:

Für den Nutzer ist es jedoch durch die OpenID-Architektur einfacher, eine Login-Seite auf Echtheit zu überprüfen, da er sich die sicherheitsrelevanten Merkmale nur einer einzigen Login-Seite merken muss, statt von mehreren, wie es ohne Single Sign-on der Fall ist. Die OpenID-Provider sorgen ebenfalls für mehr Sicherheit, indem sie etwa Cookies setzen, ein individuelles Bild zeigen, den HTTP-Referer mit der IP des Requesters vergleichen oder indem sie ein clientseitiges TLS-Zertifikat zur Authentifizierung nutzen. Insbesondere letzteres wird von immer mehr Providern unterstützt.

Natürlich kann man durch eine Bildschirmmeldung darauf hinweisen dass die eingegebenen Anmeldedaten ausschliesslich dazu verwendet werden, die Anwendung gegenüber dem Zieldienst (zum Beispiel Google Calendar) zu authentifzieren.

Aber nachprüfen kann man das als Anwender nicht, wogegen die browserbasierte Anmeldung wie im Demo von sync-components viel weniger Möglichkeiten eines Passwortklaus bietet.

Nachtrag: eine schematische Darstellung wie eine OpenID anmeldung funktioniert ist hier


How Does OpenID Work?

Nachdem man sich einmal angemeldet hat, braucht man für andere Consumer keine Anmeldung mehr, auch nicht wenn man den Browser schliesst oder den Rechner neu startet.

Auch im Demo von sync-components wird man nicht mehr auf die Loginseite des OpenID-Providers weitergeleitet, wenn man sich zuvor im normalen Browser (!) per OpenID angemeldet hat - sondern nur auf das "trust form", und auch das nur einmalig bzw. bis man die RefreshToken.ini löscht.

(p.s. habe gerade bemerkt dass es in diesem Thema nicht um OpenID sondern OAuth 2.0 geht ... knapp vorbei ist auch daneben

[Mavarik]

Ich nehme jetzt die TMS Komponenten...

Version 1.5 funktioniert!

Noch ein paar kleine Bugs, aber die werden erfahrungsgemäß vom TMS ja schnell behoben!

Mavarik