Beispiel Login REST API

Silas K.

"moin" - wohl auch ein Nordlicht ;-).
Danke für die Antwort.

Zu deiner Frage: Wir haben viele Inhalte die sich nicht in Churchtools abbilden lassen und die wir bisher in einem Internbereich unser Wordpressseite verwalten. Die Idee ist nun, dass alles über diesen Internbereich läuft, damit die Leute sich nur auf einer Seite einloggen müssen. Natürlich wird das sehr viel Arbeit und es ist noch nicht klar, ob wir das stemmen können.

Die Blogposts beschrieben nur wie man seine Profildaten in Churchtools bearbeitet oder? Gibt es auch eine Einführung wie man die Rest API nutzt. Ich verstehe dass einige routes öffentlich sind und andere einen Zugang brauchen, aber ich verstehe noch nicht, wo der Nutzer seine Zugangsdaten an die REST API schickt um sich autorisieren zu lassen. Das geht ja in der App auch irgendwie. Oder habe ich da grundlegend was nicht verstanden?

Liebe Grüße
Silas

hbuerger

Nordlicht, eher nicht, aber ich habe mir irgendwann das "Moin" angewöhnt, weil ich es schön finde ^^

Ok, das ist eine Mamut Aufgabe, die ihr euch da stellt. Aber dafür ist ja die API da

Als erstes würde ich dir empfehlen meinen Post hier zu lesen: https://forum.church.tools/topic/5121/restful-api-vorstellung - Da findest du auch den Link zur REST API Dokumentation.

Authentifizierung: Du gibt beim Request einen Query Parameter login_token mit. Den Login Token kannst du in der Personen Liste > Berechtigungen bekommen. Nach dem ersten Request bekommst du einen Cookie, den schickst du am besten in Folge Requests mit, damit deine Session verwendet wird. So muss nicht bei jedem Request die Berechtigungen berechnet werdne.

Für deinen Use-Case kannst du die Endpoints GET /persons/{id} und PATCH /persons/{id} verwenden. Über den Patch kann eine Person ihre eigenen Daten bearbeiten (sofern die Rechte gesetzt sind dafür).

Silas K.

Hallo,

Den Post habe ich schon gelesen. Danke.

danke für die Antwort, das hilft schon mal die grundsätzliche Logik besser zu verstehen. So ganz habe ich es aber immer noch nicht...

Wenn ich dich richtig verstehe bedeutet das ja, dass man sich nur einloggen kann, wenn man seinen login_token zur Hand hat. unsere Gemeindemitglieder haben das natürlich nicht und in der offiziellen App gibt man den ja auch nicht ein. Ich habe hier mal einen Screenshot mit meinem Anmeldeschirm.

So wie ich das bisher verstehe ginge das ja gar nicht, weil ich ja meinen Login_token zuerst aus Churchtools holen müsste. Aber wie macht das dann die ofizielle App? Bzw. Wie ist das dann mit der API gedacht? Irgendwie macht es noch nicht Klick, sorry.

Bild Text

davidschilling

@Silas-K In der neuen Api gibt es auch einen Endpunkt für den Login:

POST /api/login da schickst du einfach Username und Passwort als Body mit:

{"username": "foo", "password": "bar"}

Da kommt ein Session Cookie zurück. Wenn du das bei darauffolgenden Anfragen mitschickst bist du eingeloggt.

Das Login Token nutzen wir in der App um uns wieder einzuloggen wenn die Session ausläuft. Das ist nach einem Tag.

Silas K.

Hey @davidschilling: Sehr nice. Das hab ich gesucht. War aber glaube ich nicht dokumentiert.

Ich bekomme jedoch immer einen 401:

status: 401
statusText: "Unauthorized"
error: "Session expired!"

Als Header habe ich: 'Content-Type': 'application/json' gesetzt. Das ganze läuft über einen Angular Proxy, falls das wichtig ist. Den body habe ich mit JSON.stringify ausgegeben. Muss ich noch andere header setzen?

Sorry, falls ich hier irgendeinen Denkfehler mache, aber vielleicht könnt ihr mir helfen.

davidschilling

@Silas-K gibts Fehler in der JS-Console? Ich vermute mal es sollte CORS Probleme geben.

Silas K.

@davidschilling
Komisch dafür nehme ich doch gerade den Angular Proxy, aber wahrscheinlich hast du recht. Bei Angular kann man einen Popxy einrichten, der dann auf dem webpack development server läuft und die Anfragen von da aus stellt, aber scheinbar klappt das nicht. Der ganze Fehlercode in der Console lautet:

headers: HttpHeaders {normalizedNames: Map(0), lazyUpdate: null, lazyInit: ƒ}
status: 401
statusText: "Unauthorized"
url: "http://localhost:8100/api/login"
ok: false
name: "HttpErrorResponse"
message: "Http failure response for http://localhost:8100/api/login: 401 Unauthorized"
error: "Session expired!"

Könntest du einmal grob skizzieren wie das optimale Szenario in einer "Production Environment" aussehen würde in der eine PWA auf die API zugreift? Brauche ich einen Proxy Server (NodeJS oder PHP) online der meine Anfragen weiterleitet?

Wenn ich Postman (https://www.getpostman.com/) nutze klappt alles, nur aus meiner PWA klappt es nicht. Ob mit oder ohne Proxy.

Sorry für die Fragen. Ich habe noch nicht viel mit Authetication bei REST APIs gearbeitet.

Nachtrag:
Bzw. Anders gefragt, von wo darf denn ein Zugriff auf die API stattfinden, wenn Postman es schafft, aber meine PWA nicht?

Silas K.

Hat sich ziemlich erledigt, auch wenn es interessant wäre was ihr dazu sagt. Ich habe mir einen kleinen PHP Proxy gebaut, damit komm ich erst mal weiter.

davidschilling

Ich vermute dein Angular Proxy hat dann nicht richtig funktioniert.

Man kann in ChurchTools CORS Header festlegen. Das kann über den Support getan werden.

Diese beiden Werte wären für dich in der ChurchTools Config nötig:

access_control_allow_origin=http://deine-domain
access_control_allow_credentials=true

hbuerger

@Silas-K sagte in Beispiel Login REST API:

Nachtrag:
Bzw. Anders gefragt, von wo darf denn ein Zugriff auf die API stattfinden, wenn Postman es schafft, aber meine PWA nicht?

Kurze Ergänzung dazu. CORS (Mozilla MDN) ist ein Schutzmechanismus im Web. Ganz einfach gesprochen: Der Browser verhindert das nachladen von Daten (Skripts, CSS, API Calls, etc.) wenn der Origin (in diesem Fall ChurchTools) diese Seite nicht explizit das Laden erlaubt. Damit soll verhindert werden, dass im Frontend Schadcode von fremden Quellen einfach so geladen werden kann.

Wenn du PHP verwendest, dann läuft das auf einem Server. Backend also hier kannst du die ChurchTools API ohne Probleme aufrufen. Dass dein Server gehackt wurde und Schadecode ausliefert ist eher unwahrscheinlich.

Es lohnt sich das Thema CORS anzugucken. So ist es doch ein wichtiges Sicherheitskonzept im Web.