Beim Verwenden des Endpunkts /admin/users/sync_sso zum Synchronisieren von SSO-Daten ist es nicht möglich, den Namen eines Benutzers aus dem Konto zu entfernen, selbst wenn dies nicht erforderlich ist. Mit anderen Worten: Es ist nicht möglich, den Namen eines Kontos von etwas auf nichts zu ändern. Dies tritt auf, wenn full_name_required = false (und sso_overrides_name = true) gesetzt ist.
Ich vermute, dass das Problem hier liegt:
aber ich befürchte, dass meine Kenntnisse in Ruby/Discourse nicht ausreichen, um einen PR einzureichen.
Entschuldigung, aber ich bin anderer Meinung. Ich sehe nicht, wie dies eine Feature-Anfrage und kein Fehler sein kann.
Ich verstehe, dass es andere API-Endpunkte gibt, die verwendet werden können. Aber der Hauptzweck von /admin/users/sync_sso besteht genau darin, diese Art von Daten synchron zu halten. Es ist bereits möglich, das Feld für den Kontonamen festzulegen – das funktioniert. Allerdings wird davon ausgegangen, dass der Name immer ein erforderliches Feld ist, und es kann nicht leer gesetzt werden. Daher kann es nicht verwendet werden, um Daten synchron zu halten.
Der folgende Code scheint in meiner Sandbox wie erwartet zu funktionieren, aber ich fühle mich derzeit nicht sicher genug, um einen PR einzureichen. Fühlen Sie sich frei, ihn zu verwenden/anzupassen usw.
- if SiteSetting.sso_overrides_name && user.name != name && name.present?
- user.name = name || User.suggest_name(username.blank? ? email : username)
+ if SiteSetting.sso_overrides_name && user.name != name
+ if SiteSetting.full_name_required && name.present?
+ user.name = name || User.suggest_name(username.blank? ? email : username)
+ else
+ user.name = name
+ end
Noch einmal: Ich kenne die Interna (oder Ruby) nicht gut genug… aber gibt es keine Möglichkeit zu wissen, ob das Feld name in dieser Anfrage übermittelt wurde? Wenn es gar nicht vorhanden ist, das Namensfeld des Kontos nicht ändern. Wenn der Feldname übermittelt wurde, ihn setzen (falls leer, leeren). Würde das nicht das Protokoll/das Verhalten respektieren, bei dem nur die bereitgestellten Felder synchronisiert werden?
Entschuldige, falls das keinen Sinn ergibt – ich versuche nur, basierend auf meinem Verständnis etwas zu verstehen.
Das Problem ist, dass die Protokollsemantik des Parameters “name” nun so ist, dass er vorhanden und auf leer gesetzt ist, was dem Fehlen des Parameters “name” entspricht. Er berührt ihn einfach nicht.
Eine Änderung hier ist eine Änderung der Protokollsemantik. Wir könnten zwar ändern, dass name= bedeutet, dass der Name geleert wird, und das Fehlen von name bedeutet “Name nicht berühren”, aber da sich viele bereits auf das alte Verhalten verlassen, ist dies technisch gesehen eine brechende Änderung.
Wir entfernen nicht die Namen aller Benutzer – die Nutzer aktualisieren ihre eigenen Daten, wenn sie ihr Konto auf unserer Website (SSO-Anbieter) aktualisieren. Wir verlassen uns auf /admin/users/sync_sso, um die Daten (Benutzername, Name, Avatar usw.) in ihrem Discourse-Konto synchron zu halten. Das Feld Name ist optional und kann leer gesetzt werden.
Mir ist gerade aufgefallen, dass das Problem nicht nur beim Namen auftritt, sondern auch bei der Aktualisierung von Bio, Avatar usw.: Es ist nicht möglich, diese SSO-Datensätze über /admin/users/sync_sso synchron zu halten, wenn sie auf leer/blank aktualisiert werden müssen, unabhängig davon, ob sie Pflichtfelder sind oder nicht.
Ich verstehe den Einwand, dass sich einige auf das bestehende Verhalten verlassen könnten (obwohl bisher niemand dieses Problem gemeldet hat?), aber wenn dies das Protokoll ist, scheint es für seinen Zweck, SSO-Datensätze zu synchronisieren, erhebliche Einschränkungen zu haben.
Ich bin ebenfalls davon betroffen: Einzelne Benutzer können ihre persönlichen Daten (Name, Avatare, Bio, benutzerdefinierte Felder usw.) nicht selbst aus Discourse entfernen, was, wie Sie sich vorstellen können, weitreichende Folgen hat.
Ich stimme zu, dass die Semantik der aktuellen Funktionsweise nicht geändert werden sollte. Könnten Sie jedoch nicht zulassen, dass wir diese Attribute im SSO-Payload explizit auf false setzen oder etwas Ähnliches tun, um deren Löschung zu signalisieren?
Zuvor umgingen wir diese SSO-Beschränkung, indem wir den Aufruf an /admin/users/sync_sso mit einem weiteren Aufruf an den Endpunkt /u/{username} kombinierten, nur um den Namen zu leeren (falls der neue Wert für den Namen leer war).
Dies scheint jedoch in einer neueren Version aus irgendeinem Grund nicht mehr zu funktionieren, möglicherweise weil geprüft wird, ob sso_overrides_name = true ist, bevor der Name aktualisiert wird.
Wenn also SSO und sso_overrides_name = true verwendet werden, scheint es jetzt unmöglich zu sein, das Namensfeld in Discourse über die API vom SSO-Anbieter leeren zu lassen.
Sehen Sie eine Möglichkeit, dies zu umgehen, @sam?
Ich vermute, ein zusätzlicher Parameter für unsere sync_sso-Route ist angebracht? So etwas wie &clear_name, bin mir nicht sicher. Das fühlt sich wie ein solcher Grenzfall an. Was ist der Anwendungsfall für leere Namen? Vielleicht einfach auf den Benutzernamen setzen, wenn Sie keinen haben, und die Benutzeroberfläche kann Duplikate unterdrücken.
Es ist für mich verwirrend, dass Sie dies als Sonderfall betrachten. Ich nehme an, Sie sind also an Fälle gewöhnt, in denen der Name das erforderliche Feld ist.
Wir haben es umgekehrt: Der Benutzername ist das, was jeder haben muss, und der Name ist ein optionales Feld (wir verwenden prioritize_username_in_ux = true und full name required = false). Denken Sie an Twitter-Konten, bei denen jeder einen Benutzernamen/ein Handle haben muss und optional auch einen Namen haben kann. Ich glaube nicht, dass es ein Sonderfall ist, wenn man das Namensfeld (oder andere persönliche Daten) löschen möchte.
Derzeit ist es unmöglich, einen einmal eingegebenen Namen zu entfernen. Dies war eine Einschränkung von sync_sso, die wir mit einem zusätzlichen API-Aufruf zur Aktualisierung des Benutzers umgangen haben, aber jetzt funktioniert auch das nicht mehr.
Wir haben es in Betracht gezogen, aber es verleitet einige Leute zu der Annahme, dass der Benutzername auch ihr richtiger Name ist: Wir betreiben ein internationales Forum und es ist oft nicht klar, was der Name einer Person und was ein Benutzername ist (außer durch ihre Position in der Benutzeroberfläche).
Ich sollte erwähnen, dass, wenn mich meine Erinnerung nicht trügt, genau das gleiche Problem beim Entfernen des Avatars über sync_sso auftritt, da dies meiner Meinung nach auch nicht funktioniert – wir umgehen dies, indem wir unsere eigene URL für einen Standardavatar bereitstellen.
Wenn es mehrere Felder gibt, die man auf irgendeine Weise nicht löschen kann, vielleicht ein Array (oder eine CSV-Liste) von Feldern, die gelöscht/zurückgesetzt werden sollen?
Was wäre nötig, um eine Einigung über einen Weg zur Erreichung dieses Ziels zu erzielen? Ich bin gerne bereit, auf meiner Seite alles zu implementieren: einen neuen Parameter, einen speziellen Wert, einen zweiten API-Aufruf. Aber die Situation ist aus meiner Sicht kein Grenzfall. Wie @mentalstring oben, synchronisiere ich mich mit einer externen Wahrheitsquelle, bei der das Festlegen eines Profilbildes und eines Anzeigenamens optional ist. Der Benutzer darf sie nicht haben. Discourse erlaubt es, sie nicht festzulegen. Wenn Sie kein SSO verwenden, können Sie sie frei festlegen und entfernen. DiscourseConnect bricht dies: Sobald sie festgelegt sind, können sie nie wieder entfernt werden, was meiner Meinung nach ein (sehr kleiner) Fehler ist.
Ich verstehe die Bedenken hinsichtlich der Änderung des Protokolls, bei dem leer derzeit keine Änderung bedeutet. Persönlich stimme ich dem nicht zu, ich denke, es ist eine unkomplizierte und vernünftige Art, das Protokoll zu interpretieren, und das Risiko ist winzig: Es wäre sehr seltsam, wenn Systeme so implementiert würden, dass sie immer Namens- und Avatar-URL-Werte senden, sie aber manchmal auf leer setzen und erwarten, dass dies bedeutet, den alten Wert beizubehalten. Und wenn es welche gibt, die das tun, ist die Folge nur, dass Name und Avatar gelöscht werden, und es sollte eine einfache Korrektur sein.
Aber wie auch immer, ich möchte diesen Punkt nicht diskutieren, aber ich möchte die Argumentation darlegen, dass dies eine notwendige Funktion ist. Ich bin bereit, den PR zu machen, ich möchte nur wissen, welche Lösung akzeptiert würde.
Da dies bei mindestens name und avatar_url und möglicherweise anderen (ich glaube auch website?) vorkommt, vielleicht ein reset_fields-Parameter mit einer Liste von Feldern, die gelöscht werden sollen, anstelle mehrerer einzelner clear_x-Felder?
Für uns wäre es schon nützlich, wenn wir es mit zusätzlichen Aufrufen an den /u/{username}-Endpunkt beheben könnten, aber auch das hat irgendwann aufgehört zu funktionieren.