Version 3.116.0

davidschilling

@liebsoer Welchen Internal Name meinst du? Auf CT oder Nextcloud Seite? Und funktioniert es bei dir jetzt grundsätzlich?

davidschilling

@niko In der App funktioniert die Registrierung ab der Version 0.62.0. Die wird jetzt nach und nach ausgerollt. Also noch ein bisschen gedulden. Dann sollte es funktionieren.

liebsoer

@davidschilling Den Internal Name bei der Social Login Konfiguration. In ChurchTools kann der Config Name Leerzeiche enthalten.
Nextcloud gibt mir die Fehlermeldung Invalid provider name "Name mit Leerzeichen". Allowed characters "0-9a-z_.@-".

Ich bekomme nach wie vor die Fehlermeldung {"error":"invalid_client","error_description":"Client authentication failed"}, wenn ich versuche den OAuth Login zu verwenden:

Die Url
http://localhost:8080/index.php/apps/sociallogin/custom_oauth2/$CT_CONFIG_NAME

Die URL sieht wie folgt aus: https://$GEMEINDE.church.tools/oauth/authorize?response_type=code&client_id=$CLIENT_ID&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Findex.php%2Fapps%2Fsociallogin%2Fcustom_oauth2%2FLKGNextcloud&scope=&state=$STATE

Und ich teste das ganze gerade in einer lokalen Nextcloud instanz. Gibt es da noch einen Zusammenhang?

davidschilling

@liebsoer Ich denke es sollte auch mit einer lokalen Nextcloud funktionieren.
Kannst du mal Screenshots von der Konfig in CT und Nextcloud zeigen? Der Identifier in CT und in Nextcloud sollte geschwärzt werden.

liebsoer

@davidschilling So sehen meine Configs aus:

ChurchTools Config:

Nextcloud Config:

davidschilling

@liebsoer Sieht nicht falsch aus.
Den Groups claim kannst du rausnehmen. Und ist dein Internal name "ChurchTools"? Der muss der gleiche wie in der Redirect-URI in CT am ende sein.

liebsoer

@davidschilling Ja, der interne Name bei meiner lokalen Instanz ist ebenfalls ChurchTools. Was gibt es für Möglichkeiten, dass ich das debuggen kann?

davidschilling

@liebsoer Dieser Fehler tritt auf, wenn die Redirect-Uri die du auf CT-Seite eingetragen hast nicht mit der übereinstimmt, die die Nextcloud an CT mitliefert. Diese muss ganz genau übereinstimmen. Die solltest du urlencoded beim Redirect auf CT in der URL sehen können.

liebsoer

@davidschilling Danke für den Hinweis! Jetzt geht es bei mir

Die Redirect URL ist nicht wie in der Doku angegeben http://$SERVER/apps/sociallogin/custom_oauth2/$INTERNAL_NAME sondern http://$SERVER/index.php/apps/sociallogin/custom_oauth2/$INTERNAL_NAME

JosuaDev

@davidschilling nein ich meine die Datenschutzerklärung. Die musste man ja immer mit dem Geburtsdatum und dem Kontrollkästchen bestätigen. Bei der Registrierung reicht zurzeit nur das Kontrollkästchen, was ja gegen den Datenschutz verstößt, weil sich dann auch Menschen unter 16 Jahre den Datenschutz akzeptieren können.

niko

@davidschilling Top, funktioniert mittlerweile. Danke!

Zum dem anderen Thema: Könnt ihr mir rückmelden, ob mein Thema verstanden wurde? Es geht mir gar nicht darum, dass sofort was unternommen werden muss. Ich würde mich nur freuen, wenn es nachvollziehbar ist und in den Fokus gerückt werden könnte. Denn ich bin wirklich überzeugt davon, dass es viele Gemeinde betreffen müsste.

MichaelG

@niko ich müsste das noch mal testen, aber ist es nicht bereits so, dass du nur im Kontext deines Standortes bist, wenn nicht explizit weitere Standorte berechtigt wurden.
Was für einen Vorteil hast du durch die Bereiche?

Eine Idee wären automatische Gruppen. Du hast eine Gruppe pro Standort und berechtigst dann auf die Gruppen. Dann brauchst du die Bereiche nicht mehr

niko

@MichaelG sagte in Version 3.116.0:

@niko ich müsste das noch mal testen, aber ist es nicht bereits so, dass du nur im Kontext deines Standortes bist, wenn nicht explizit weitere Standorte berechtigt wurden.
Was für einen Vorteil hast du durch die Bereiche?

Eine Idee wären automatische Gruppen. Du hast eine Gruppe pro Standort und berechtigst dann auf die Gruppen. Dann brauchst du die Bereiche nicht mehr

Hi Michi!
Ich würde das nutzen von Bereichen nicht als Vorteil bezeichnen. Es ist vielmehr für uns der einzige Weg, komplette Personenlisten eines Standorts sichtbar zu machen. Deine Frage, ob man nicht eh im Kontext eines Standort ist, würde ich mich "nein" beantworten. Zumindest nicht, wenn es um die ganze Personenliste eines Standorts geht. Ich habe die Szenarien, um die es geht, in diesem Beitrag hier erklärt, wir können gerne dort auch weitermachen. https://forum.church.tools/topic/5809/alle-personen-eines-standorts-station-sichtbar-machen/12?_=1733995444298

Kann man damit verstehen, was unser "Problem" ist?

PS: Die automatischen Gruppen haben wir schon. Aber der Workaround, die entsprechenden Leute dort als Leiter einzufügen, wäre für mich kein guter Workaround, weil das betrifft ja mehrere Teams und ich müsste manuell jeden als Leiter einfügen. Oder als übergordnete Gruppe dazu, das finde ich nicht gerade handlich. Aber schau dir einfach die von mir beschriebenen Szenarien an, dann versteht man das glaube.

aschild

Wir haben soeben unsere Wordpress Webseite mit dem SSO integriert.
Dazu haben wir das "Authorizer" Plugin verwendet.

Soweit war es einfach das zu integrieren.

Was nicht so intuitiv war:
Die Callback URL ist zwar beim Plugin angegeben, aber an einer seltsamen Stelle.
https://meine.webseite.ch/wp-login.php?external=oauth2

Was gar nicht intuitiv ist:
Das secret wird NICHT von Churchtool vergeben, sondern man muss irgend ein zufälliges Secret im Client einfügen, und Churchtool speichert das dann für die Zukunft in seiner DB.
Da sollte im CT mindestens ein Hinweis kommen, ev. in Form eines Feldes unter der Client ID wo was für's Setup erklärt wird.

Ansonsten scheint es zu funktionieren.
Hoffentlich stabiler als der aktuell LDAP Dienst, welcher alle Nextcloud User Offline setzt, wenn eine neue CT Version ausgerollt wird.