Fehler bei der Verwendung des discourse-oauth2-basic-Plugins mit NeonCRM

[Denis_Heraud]

Ich versuche, das Plugin discourse-oauth2-basic einzurichten, damit sich unsere Benutzer mit ihren über NeonCRM erstellten und gespeicherten Zugangsdaten in unserem Discourse-Forum anmelden können.

Ein NeonCRM-Supporttechniker hat mir erklärt, dass ich die Autorisierungs-URL manuell in diesem Format erstellen kann:

https://{{Org ID}}.z2systems.com/np/oauth/auth?response_type=code&client_id={{Client ID}}&redirect_uri={{Redirect URL}}

In Discourse habe ich folgende Parameter für das Plugin festgelegt:

oauth2 client id: MY-CLIENT-ID
oauth2 client secret: MY-CLIENT-SECRET
oauth2 authorize url: https://MY-NEON-ID.z2systems.com/np/oauth/auth
oauth2 token url: https://www.z2systems.com/np/oauth/token

Ich habe also diese URL manuell erstellt (die ich zensiert habe):

https://MY-NEON-ID.z2systems.com/np/oauth/auth?response_type=code&client_id=MY-CLIENT-ID&redirect_uri=https://MY-FORUM.COM/auth/oauth2_basic/callback

Wenn ich diese URL in einem Browser eingebe, wird eine Discourse-Seite mit folgender Meldung angezeigt:

Und meine Logs zeigen:

(oauth2_basic) Authentication failure! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRF detected

Warum?

[Denis_Heraud]

Wenn ich stattdessen diese URL verwende:

https://MY-NEON-ID.z2systems.com/np/oauth/auth?response_type=code&client_id=MY-CLIENT-ID&redirect_uri=https://MY-FORUM.COM/

(Ich habe den Callback-Teil am Ende meiner redirect_uri entfernt)

gelange ich tatsächlich zur NeonCRM-Login-Seite. Dort gebe ich meine Test-Benutzerdaten ein und melde mich an. Anschließend werde ich zu MY-FORUM.COM weitergeleitet. Sobald ich dort bin, bin ich jedoch überhaupt nicht eingeloggt. Wenn ich oben auf der Seite auf die Schaltfläche „Anmelden

[Falco]

@Denis_Heraud

redirect_uri=http://MEIN-FORUM-URL.COM/

Diese redirect_uri ist falsch. Sie müssen sie korrekt einstellen, damit der Ablauf funktioniert.

In der Plugin-Dokumentation steht dies als Erstes im Abschnitt Grundlegende Einrichtung.

NeonCRM dokumentiert ebenfalls, wie man dies in ihrer Dokumentation einrichtet.

[Denis_Heraud]

Danke @Falco!

Ich habe versucht, die redirect_uri auf Folgendes zu setzen:

https://MY-FORUM.COM/auth/oauth2_basic/callback

Das hat jedoch nicht funktioniert. Siehe meinen ursprünglichen Beitrag (den ich gerade bearbeitet habe, damit er weniger verwirrend ist – entschuldige, falls du ihn übersehen hast).

[Falco]

Läuft dein Forum über HTTPS?

[Denis_Heraud]

Ja, das ist @Falco.

https://forum.efao.ca/

[Falco]

Haben Sie die Einstellung force_https aktiviert?

[Denis_Heraud]

@Falco, ich habe Anweisungen gefunden, um force_https zu aktivieren, und habe es auf true gesetzt.

Trotzdem erhalte ich denselben Fehler.

[Denis_Heraud]

Ich habe das Widget, das NeonCRM für den oberen Bereich des Forums empfiehlt, integriert (damit du es bei Bedarf selbst ausprobieren kannst) unter

https://forum.efao.ca/

Wenn ich das Widget verwende, erhalte ich dasselbe Ergebnis wie in meinem ursprünglichen Beitrag.

(oauth2_basic) Authentifizierungsfehler! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRF erkannt

[Denis_Heraud]

Jemand? @david oder @Falco?

[david (David Taylor)]

@Denis_Heraud

ArgumentError (Ungültige URI: )

/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/excon-0.64.0/lib/excon.rb:126:in `new’

Im oauth2-Plugin verwenden wir Excon ausschließlich an dieser Stelle:

plugin.rb

Welchen Wert ist für oauth2_user_json_url eingestellt? Ich vermute, er ist leer. Falls ja, solltest du auch oauth2_fetch_user_details deaktivieren, damit Discourse nicht versucht, eine leere URL aufzurufen.

[Denis_Heraud]

@david, es ist tatsächlich leer.

Ich weiß nicht, was ich als oauth2_user_json_url einstellen soll. Leider habe ich Pech gehabt, als ich versuchte, NeonCRM über deren technischen Support dabei zu helfen, das herauszufinden.

Wenn ich versuche, es zu deaktivieren, erhalte ich eine Meldung, dass ich oauth2 callback user id path einstellen muss, aber wie oben erwähnt, weiß ich nicht, welcher Wert dafür verwendet werden soll.

[david (David Taylor)]

Ich habe keine NeonCRM-Installation, um es damit zu testen, aber ich denke, die Einstellung auf access_token sollte funktionieren. Können Sie das versuchen?

Aus der von Falco oben verlinkten Dokumentation:

Antwort

Die Serverantwort wird bei Erfolg ein JSON mit dem Zugriffstoken des Benutzers zurückgeben.

{"access_token":"101177"}

Dieses Zugriffstoken ist einfach die NeonCRM-Konto-ID des Benutzers.

[Denis_Heraud]

Gleicher Fehler:

(oauth2_basic) Authentifizierungsfehler! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRF erkannt

Backtrace:

 /var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.3.2/lib/logster/logger.rb:110:in `report_to_store'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.3.2/lib/logster/logger.rb:101:in `add_with_opts'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.3.2/lib/logster/logger.rb:52:in `add'
/usr/local/lib/ruby/2.6.0/logger.rb:543:in `error'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:163:in `log'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:486:in `fail!'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-oauth2-1.6.0/lib/omniauth/strategies/oauth2.rb:71:in `callback_phase'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:238:in `callback_call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:189:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:169:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:192:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:169:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:192:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:169:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:192:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:169:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:192:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:169:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/builder.rb:64:in `call'
/var/www/discourse/lib/middleware/omniauth_bypass_middleware.rb:30:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/tempfile_reaper.rb:15:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/conditional_get.rb:25:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/head.rb:12:in `call'
/var/www/discourse/lib/content_security_policy/middleware.rb:12:in `call'
/var/www/discourse/lib/middleware/anonymous_cache.rb:218:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/session/abstract/id.rb:232:in `context'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/session/abstract/id.rb:226:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-5.2.3/lib/action_dispatch/middleware/cookies.rb:670:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-5.2.3/lib/action_dispatch/middleware/callbacks.rb:28:in `block in call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/activesupport-5.2.3/lib/active_support/callbacks.rb:98:in `run_callbacks'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-5.2.3/lib/action_dispatch/middleware/callbacks.rb:26:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-5.2.3/lib/action_dispatch/middleware/debug_exceptions.rb:61:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-5.2.3/lib/action_dispatch/middleware/show_exceptions.rb:33:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.3.2/lib/logster/middleware/reporter.rb:43:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-5.2.3/lib/rails/rack/logger.rb:38:in `call_app'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-5.2.3/lib/rails/rack/logger.rb:28:in `call'
/var/www/discourse/config/initializers/100-quiet_logger.rb:18:in `call'
/var/www/discourse/config/initializers/100-silence_logger.rb:31:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-5.2.3/lib/action_dispatch/middleware/remote_ip.rb:81:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-5.2.3/lib/action_dispatch/middleware/request_id.rb:27:in `call'
/var/www/discourse/lib/middleware/enforce_hostname.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/method_override.rb:22:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-5.2.3/lib/action_dispatch/middleware/executor.rb:14:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/sendfile.rb:111:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-mini-profiler-1.1.0/lib/mini_profiler/profiler.rb:184:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-2.2.0/lib/message_bus/rack/middleware.rb:57:in `call'
/var/www/discourse/lib/middleware/request_tracker.rb:163:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-5.2.3/lib/rails/engine.rb:524:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-5.2.3/lib/rails/railtie.rb:190:in `public_send'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-5.2.3/lib/rails/railtie.rb:190:in `method_missing'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/urlmap.rb:68:in `block in call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/urlmap.rb:53:in `each'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/urlmap.rb:53:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.1/lib/unicorn/http_server.rb:605:in `process_client'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.1/lib/unicorn/http_server.rb:700:in `worker_loop'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.1/lib/unicorn/http_server.rb:548:in `spawn_missing_workers'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.1/lib/unicorn/http_server.rb:144:in `start'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.1/bin/unicorn:128:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `load'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `<main>'

[david (David Taylor)]

Interessant… der Backtrace deutet darauf hin, dass der Fehler aus diesem Teil der OAuth2-Bibliothek stammt. Das bedeutet, dass der state-Parameter nicht korrekt abgeglichen wird.

Um sicherzugehen: Stammen diese Fehlermeldungen von deiner Produktionsseite? Ich habe versucht, mich dort einzuloggen, und von meiner Seite aus sieht es so aus, als würde der state-Parameter korrekt weitergegeben.

Das deutet auf ein Problem auf der Serverseite hin. Wie wird deine Seite gehostet? Hast du unsere Standardprozedur befolgt?

[Denis_Heraud]

Auch @david, und ich weiß nicht, ob das damit zusammenhängt, aber ich habe auch diesen separaten Eintrag in unseren Logs:

Job exception: SSL_connect returned=1 errno=0 state=error: certificate verify failed (self signed certificate)

Wir verwenden Let’s Encrypt für unser SSL-Zertifikat.

[david (David Taylor)]

Ist dieser Fehler mit einem Backtrace versehen?

[Denis_Heraud]

@david

Kannst du bestätigen, dass dieser Fehler von deiner Produktionsseite? stammt. Ich habe versucht, mich dort einzuloggen, und von meiner Seite aus sieht es so aus, als würde der Status korrekt weitergegeben.

Das deutet auf ein Problem auf der Serverseite hin. Wie wird deine Seite gehostet? Hast du unser Standardverfahren befolgt?

Ja, forum.efao.ca ist unsere Produktionsseite. Wir sind bei Digital Ocean gehostet und die Installation erfolgte nach dem Standardverfahren.

[Denis_Heraud]

@david

Ist mit diesem Fehler ein Backtrace verknüpft?

/usr/local/lib/ruby/2.6.0/net/protocol.rb:44:in `connect_nonblock'
/usr/local/lib/ruby/2.6.0/net/protocol.rb:44:in `ssl_socket_connect'
/usr/local/lib/ruby/2.6.0/net/pop.rb:553:in `do_start'
/usr/local/lib/ruby/2.6.0/net/pop.rb:531:in `start'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:43:in `poll_pop3'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:18:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rails_multisite-2.0.7/lib/rails_multisite/connection_management.rb:63:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
/var/www/discourse/app/jobs/base.rb:279:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/mini_scheduler-0.11.0/lib/mini_scheduler/manager.rb:83:in `process_queue'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/mini_scheduler-0.11.0/lib/mini_scheduler/manager.rb:34:in `block in initialize'

[david (David Taylor)]

Ich befürchte, dass ich ohne Zugriff auf den Server nicht viel mehr tun kann, um dies zu diagnostizieren. Viele Nutzer verwenden das oauth2-Plugin problemlos, daher denke ich, dass es sich um ein Konfigurationsproblem irgendwo handelt. Das Einzige, was vielleicht noch helfen könnte, ist ein Upgrade auf die neueste Version von Discourse, anstatt den stabilen Zweig zu verwenden.

Vielleicht meldet sich jemand anderes aus der Community zu Wort, aber falls nicht, könntest du im Marketplace um Hilfe bitten und dort eventuell Erfolg haben.