search

milux / ctldap

LDAP Wrapper for ChurchTools
GNU General Public License v3.0
12 stars 8 forks source link

Error with Churchtools 3.56.0 "CSRF-Token is invalid" #21

Closed sscholl closed 4 years ago

sscholl commented 4 years ago

Nach dem Update auf Churchtools 3.56.0 kommt eine neue Einstellung als default. Diese verhindert, dass ctldap läuft. Ich habe gesehen, das CT @hubermat schon dran arbeitet. https://github.com/churchtools/ctldap-ms/commits/master

Unser temporärer Fix ist, die Option wieder auszustellen...

Weiteres: 

ldap_1  | Error: StatusCodeError: 401 - {"message":"A server error ocurred","translatedMessage":"server.error","messageKey":"server.error","args":[],"errors":[{"message":"CSRF-Token is invalid"}]}
ldap_1  |     at /app/ctldap.js:134:17
ldap_1  |     at tryCatcher (/app/node_modules/bluebird/js/release/util.js:16:23)
ldap_1  |     at Promise._settlePromiseFromHandler (/app/node_modules/bluebird/js/release/promise.js:517:31)
ldap_1  |     at Promise._settlePromise (/app/node_modules/bluebird/js/release/promise.js:574:18)
ldap_1  |     at Promise._settlePromise0 (/app/node_modules/bluebird/js/release/promise.js:619:10)
ldap_1  |     at Promise._settlePromises (/app/node_modules/bluebird/js/release/promise.js:695:18)
ldap_1  |     at _drainQueueStep (/app/node_modules/bluebird/js/release/async.js:138:12)
ldap_1  |     at _drainQueue (/app/node_modules/bluebird/js/release/async.js:131:9)
ldap_1  |     at Async._drainQueues (/app/node_modules/bluebird/js/release/async.js:147:5)
ldap_1  |     at Immediate.Async.drainQueues [as _onImmediate] (/app/node_modules/bluebird/js/release/async.js:17:14)
ldap_1  |     at processImmediate (internal/timers.js:439:21)
ldap_1  | Unhandled rejection TypeError: Cannot read property 'users' of undefined
ldap_1  |     at /app/ctldap.js:176:30
ldap_1  |     at tryCatcher (/app/node_modules/bluebird/js/release/util.js:16:23)
ldap_1  |     at Promise._settlePromiseFromHandler (/app/node_modules/bluebird/js/release/promise.js:517:31)
ldap_1  |     at Promise._settlePromise (/app/node_modules/bluebird/js/release/promise.js:574:18)
ldap_1  |     at Promise._settlePromise0 (/app/node_modules/bluebird/js/release/promise.js:619:10)
ldap_1  |     at Promise._settlePromises (/app/node_modules/bluebird/js/release/promise.js:699:18)
ldap_1  |     at _drainQueueStep (/app/node_modules/bluebird/js/release/async.js:138:12)
ldap_1  |     at _drainQueue (/app/node_modules/bluebird/js/release/async.js:131:9)
ldap_1  |     at Async._drainQueues (/app/node_modules/bluebird/js/release/async.js:147:5)
ldap_1  |     at Immediate.Async.drainQueues [as _onImmediate] (/app/node_modules/bluebird/js/release/async.js:17:14)
ldap_1  |     at processImmediate (internal/timers.js:439:21)
koehdaniel commented 4 years ago

Vielen Dank, den temporären Fix zu erwähnen 👍 Hat geholfen.

milux commented 4 years ago

Ich habe dasselbe getan, da bei mir gerade zeitlich zu sehr Land unter ist um es zu fixen. :( Werde mich ASAP darum kümmern, sollte eigentlich kein großes Ding sein.

hubermat commented 4 years ago

Hallo @milux, Du solltest einfach meinen letzten Commit von ctldap-ms übernehmen können.

koehdaniel commented 4 years ago

Sorry für die Frage, da sie nichts mit dem Issue zu tun hat, aber worin unterscheidet sich ctldap-ms von diesem Repo?

@milux wäre es nicht möglich in deinem Docker container das Repo von ctldap-ms zu integrieren? Oder dass @hubermat (ChurchTools) direkt ein Dockerimage bereitstellt?

So wie bisher wird es ja auch bei zukünftigen Änderungen immer mehrfachaufwände geben, deren Sinn sich mir gerade noch nicht erschließt.

a-schild commented 4 years ago

@koehdaniel Das Problem ist, dass milux seit einiger Zeit keine pull requests mehr einpflegt, womit das root Repositoty "verwaist" ist. Darum der ctldap-ms fork den mal als die aktuelle Version anschauen sollte

sscholl commented 4 years ago

@koehdaniel @a-schild @hubermat @milux Ich würde auch vorschlagen, dass ctldap durch Churchtools zentralisiert werden sollte, inkl. Docker Build. Wir sollten ein Maintainer Team bestimmen, in welchem @milux natürlich auch ist. Wenn nötig stelle ich mich als Maintainer bereit.

hubermat commented 4 years ago

Darum der ctldap-ms fork

Der Grund für unseren ctldap-Fork ist ein anderer. Wir haben den ctldap geforkt, weil wir den ctldap-ms aufbohren wollten, damit von uns für mehrere ChurchTools-Instanzen gleichzeitig ein LDAP-Service angeboten werden kann. Das ist die Basis für unseren gehosteten LDAP-Service.

Wir (ChurchTools) haben leider keine Kapazitäten, um den ctldap-ms als Docker-Build zur Verfügung zu stellen. Wenn jemand gerne den ctldap-ms privat nutzen möchte, gerne. Gerne auch, um daraus einen Docker-Build zu erstellen.

Bitte habt aber Verständnis, daß wir dafür keinen Support leisten können, das können wir nur für den von uns angebotenen gehosteten LDAP-Service, welcher eine kostenpflichtige ChurchTools-Lizenzoption ist.

milux commented 4 years ago

Hallo @milux, Du solltest einfach meinen letzten Commit von ctldap-ms übernehmen können.

Ich müsste ohnehin eine Menge von euch übernehmen... ^^

milux commented 4 years ago

@koehdaniel @a-schild @hubermat @milux Ich würde auch vorschlagen, dass ctldap durch Churchtools zentralisiert werden sollte, inkl. Docker Build. Wir sollten ein Maintainer Team bestimmen, in welchem @milux natürlich auch ist. Wenn nötig stelle ich mich als Maintainer bereit.

Die Idee gefällt mir, weil wie @a-schild schon richtig angemerkt hat: Mir fehlen gerade einfach die Ressourcen um das hier vernünftig zu maintainen, von Verbesserungen mal gar nicht zu reden... daher ist das hier "best effort".

Docker-Images kann man automatisiert bauen lassen auf Docker Hub, zumindest für x86_64 geht das total schmerzfrei. Gibt hier allerdings einige arm-User (uns selbst eingeschlossen), hier wird es dann schon komplizierter, wenn man es nicht ständig lokal mit buildx bauen möchte...

milux commented 4 years ago

@hubermat Musstet ihr Änderungen am Format der Config durchführen für eure Erweiterung?

hubermat commented 4 years ago

@milux Ist ja jetzt schon eine Weile her, aber ich glaube ich habe die Config so erweitert, dass sie rückwärtskompatibel ist, d.h. eine einzelne Gemeinde ihre bisherige ctldap-Config nutzen könnte. Im Zweifelsfall einfach mal ausprobieren! In den letzten Tage ist nochmal ein Commit mit ein paar Änderungen bezüglich der CSRF-Thematik dazugekommen.

milux commented 4 years ago

Danke, jo, scheint mir auch so. Wenn die sites leer sind, wird eine einzelne site aus den globalen Settings erzeugt. Das sieht sinnvoll aus. Habe den Code bei mir schon gemerged. Noch ein paar Anpassungen, dann veröffentliche ich vsl. heute irgendwann Version 2.2.

milux commented 4 years ago

Fixed in develop, release will follow soon. :)