2020-09-29 Keycloak – App Kommunikation

In diesem Sprint haben wir uns hauptsächlich um die Anbindung des Keycloak-Systems – unserem Identity Provider – gekümmert. Damit wollten wir eine weitere fehlende und umfangreiche Komponente unserer TeamSlimster App hinzufügen. „Wollten“ ist Präteritum? Fertig sind wir damit nämlich nicht geworden.

Generell ist das Ziel:

  1. Sich mit einem Usernamen und Passwort einzuloggen
  2. Den gelieferten Token von Keycloak einem Webservice Request zum Backend-Server mitzuschicken
  3. Dort anhand des Tokens den User authentifizieren
  4. Die angeforderten Daten zusammen sammeln
  5. Und das Ergebnis in unserer App anzuzeigen

Gestern (Montag) haben wir mit Pair Programming begonnen. Wir haben unsere Library „Identity Provider Access“ um eine Logout Funktion erweitert. Diese Library verwendet immer noch „AppAuth“ als Dependency, die uns schon in der letzte Woche Probleme bereit hat. Einen Logout bietet sie gar nicht an – soweit ich weiß. Wir sind also hingegangen und haben unsere Retrofit-Kenntnisse ausgepackt und die Funktion runterprogrammiert.
Ganz so lief es dann doch nicht. Erst einmal haben wir mit Postman rumgespielt und alle Request Parameter so befüllt, dass zumindest Postman den eingeloggten User ausloggt.
Erst im zweiten Schritt haben wir den Logout-Retrofit-Service implementiert. Auf Anhieb hat es nicht funktioniert. Logisch. Dem Body einfach die Client-ID und einen Token übergeben? Damit ist es nicht getan. Denn dabei werden bspw. Hochkomma nicht escapt. Aber Dank unserem Buddy Stackoverflow haben wir das Problem in den Griff bekommen. Logout funktioniert!

Verena

Da wir Probleme beim Einbinden zweier unserer Module hatten, habe ich mich ein bisschen in Gradle und wie Dependencies konfiguriert werden eingelesen. Die transitiven Dependencies, das Gegenteil zu direkten Dependencies, die man per „implementation“ hinzufügt, wie z.B. unser ConfigPropertiesReader, der in einem unserer Module verwendet wird, können offensichtlich nicht aufgelöst werden. Peter hatte herausgefunden, dass die einzige Möglichkeit, diese zu nutzen, ist, sie ebenfalls als direkte Dependency in unserer App anzugeben. Mal sehen, ob wir hier noch eine andere Lösung finden. Ich bin noch über „resolvable und consumable configurations“ gestolpert und werde mir das nächste Woche nochmal anschauen.

Peter

Nachdem wir die Logout-Funktion umgesetzt hatten, habe ich mich an die Token-Refresh-Funktion gemacht. Vom Keycloak System soll über den Refresh-Token ein neuer Access-Token samt zugehörigen Refresh-Token beschafft werden.

Ich bin genauso vorgegangen wie damals, vor 24 Stunden, erst mal mit Postman ran pirschen, die Attribute ausfindig machen, die wir benötigen und wie sie zu befüllen sind. Dabei habe ich festgestellt, dass der Request Body für den Logout komplett anders befüllt werden muss als der vom Token-Refresh. Statt die Attribute mit einem & zu verknüpfen, mussten sie nun als Value-Pair Liste übergeben werden. Gut, aber auch das hat Retrofit unterstützt – Hashtag FormUrlEncoded –.

Und ab da ging es etwas bergab. Ich bin so ein Update-Futzi. Darf man was updaten, update ich es. Verena hatte in der Vergangenheit schon schlechte Erfahrungen mit Android Studio und Updates gemacht. Die wollte ich einfach auch sammeln und habe frecher Weise auf „Update“ geklickt. Das Ende des Liedes waren mehrere Neuinstallationen von Android Studio, Caches löschen, SDKs-updaten, Lizenzen aktualisieren, Plattformen installieren. Was auch immer.

Ah, und wir hatten in unserer TeamSlimster App bereits eine kleine API für die etwas einfachere Nutzung von Retrofit. Da wir diese auch gut in unserer „Identity Provider Acccess“ Library gebrauchen konnten, habe ich sie in ein extra Paket gezogen, das wir nun überall in Form eines Github Repositories einbinden können.

Schreibe einen Kommentar