Das wäre eine gute Antwort für mich, außer dass ich die Header-basierte Authentifizierung nicht zum Laufen bekomme. Daher versuche ich es mit Formularen, stoße aber auch auf CSRF-Probleme. Gibt es eine Lösung? Ich versuche, über die API ein neues Thema zu erstellen.
Wir benötigen weitere Informationen, um Ihnen helfen zu können. Können Sie einen Code-Ausschnitt teilen, der zeigt, wie Sie die Header-basierte Authentifizierung verwenden möchten?
Das Problem, das ich habe, entsteht hauptsächlich dadurch, dass bei jedem Versuch, einen Aufruf mit header-basierter Authentifizierung durchzuführen, immer die Header „User-Api-Key
[quote=“tdekoekkoek, Beitrag:8, Thema:117136”]
Die akzeptierten Header sind immer „User-Api-Key
Ich erhalte einen CORS-Fehler, da der Server den Header User-Api-Key erwartet. Ich habe die erwarteten Header in der OPTIONS-Antwort geprüft, und dort steht genau das. Es gibt ein ähnliches Thema in diesem Forum, in dem ein Nutzer dieses Problem hatte, als er von einer JavaScript-App aus aufgerufen hat.
Ah, du versuchst also, diese Anfrage von einer clientseitigen JavaScript-Anwendung aus zu stellen? Das ist aus mehreren Gründen nicht erlaubt. Wenn du beispielsweise einen Admin-API-Schlüssel in den Quellcode deiner JavaScript-App einfügst, könnte jeder Benutzer vollen Admin-Zugriff auf dein Forum erhalten. Hier ist ein vorheriges Thema zu diesem Thema.
Ja, genau das versuche ich zu tun. Das sollte klarer dokumentiert werden. Das ist meine gesamte Strategie seit ich mit Discourse angefangen habe. Ich schätze deine Hilfe. Ich kämpfe seit Tagen damit und habe die Dokumentation gelesen. Ich muss meinen gesamten Ansatz überdenken, da ich derzeit eine serverlose Anwendung entwickle, obwohl ich Zugriff auf einen Node.js-Server habe.
Dies ist keine Einschränkung, die speziell für Discourse gilt – im Allgemeinen ist es eine schlechte Idee, Administratoranmeldedaten im Quellcode einer Website zu speichern.
Wenn Sie den Discourse-API-Aufruf von Ihrem Node.js-Server aus durchführen können, wäre dies wahrscheinlich die beste Lösung. Falls Ihre Anwendung ausschließlich clientseitig sein muss, besteht die Option, benutzerspezifische API-Schlüssel anzufordern, deren Einrichtung jedoch deutlich komplexer ist: User API keys specification
Ehrlich gesagt ist der Zugriff auf APIs über Client-Anwendungen mit aktiviertem CORS extrem verbreitet und Standard. Ich kann nicht glauben, dass es keine sicherere Methode dafür gibt. Eine ganze Industrie dreht sich um gehostete APIs, die von verschiedenen Domains aus abgerufen werden. Was den Zugriff mit Benutzer-APIs betrifft: Ich habe gesehen, wie man diese erstellt, bin mir aber unsicher, welche tatsächlichen Zugangsdaten erforderlich sind. Bei dieser Methode erhalte ich ständig eine 403-Fehlermeldung mit der Meldung „Zugriff verweigert“.
Ich glaube, ich befinde mich in einer ähnlichen Situation.
Ein paar Worte zum Anwendungsfall:
Ich nutze Discourse als Backend und baue das Frontend in VueJS. Ich beabsichtige, ausschließlich die REST-API zu verwenden. Für jeden Benutzer auf unserer Plattform habe ich einen eigenen API-Schlüssel erstellt und verwende sowohl die Header (Api-Key & Api-Username) zur Authentifizierung.
Jeder Benutzer authentifiziert sich sicher bei unseren Servern und erhält daraufhin sein Discourse-Token zur Authentifizierung. Anschließend möchten wir dieses Token (in einem VueJS-Frontend) verwenden, um API-Anfragen zu senden (Themen erstellen, Beiträge verfassen, bearbeiten usw.).
Nichts ist hart kodiert; alle Tokens werden nach einer ordnungsgemäßen Authentifizierung empfangen.
Das Problem:
Ich erhalte eine CORS-Fehlermeldung, obwohl ich sie in der app.yml aktiviert und im Abschnitt „Sicherheit
@david kann Discourse nicht einfach ein Sitzungsgeheimnis mit einem HMAC signieren lassen, und dieses Sitzungsgeheimnis kann wiederum verwendet werden, um Dinge in der gegebenen Sitzung zu signieren? Wenn es gestohlen wird, dann würden vermutlich die Sitzungs-Cookie oder der CSRF-Nonce auch nicht gestohlen werden. Es ist ein bisschen wie eine Zertifikatskette – man muss den Root-Schlüssel nicht im Browser hinterlegen.
Diese sind nur für die Admin-API. So wie ich es verstanden habe, müssen Sie für JavaScript-Clients, wie oben erwähnt, User API keys specification prüfen.