Vielen Dank für die Diskussion.
Ich habe den Link gelesen: Use Discourse as an identity provider (SSO, DiscourseConnect) - #8 by reverend_paco
Aber ich denke, das ist, wenn ich meine Benutzer auf eine sekundäre Website senden und die Authentifizierung dort verwalten möchte.
In meinem Fall habe ich ein Stück JS, das auf der Discourse-Website ausgeführt wird. Und ich möchte, dass dieses JS einen Pfad auf demselben Server aufruft und einen Cookie für Pocketbase zurückbekommt.
Ich verwende tatsächlich einen Nginx-Proxy vor Discourse und habe gerade eine spezielle Route /pb/auth (zum Beispiel) hinzugefügt. Wenn mein JS diese Route aufruft, akzeptiert ein Backend-Proxy-Server (der nicht in Discourse ist) diese Verbindung und versucht, den _t-Sitzungs-Cookie zu dekodieren.
Ich habe es auf diese Weise gemacht, weil es einfacher zu sein scheint, als ein Discourse-Plugin hinzuzufügen (ich bin damit und mit dem Dev-Setup usw. weniger vertraut). Wenn es sich um eine einfache Angelegenheit handelt, einen Cookie mit Base64 und SHA-Hashing zu dekodieren, dachte ich, das würde mir eine gesicherte Nutzlast liefern, die mir sagt, wer der Benutzer ist.
Aber wenn Sie denken, dass es eine einfache Möglichkeit gibt, ein Plugin zu erstellen, das diese Route zu Discourse hinzufügt, bin ich sehr daran interessiert, dies auszuprobieren. Es scheint der richtige Weg für die Zukunft zu sein. Aber ich bin ein alter Perl-Programmierer, also bevorzuge ich den faulen Weg, und meine Nginx-Route schien fauler zu sein. ![]()