# Anpassung von SSO-Inkonsistenzen

**URL:** https://meta.discourse.org/t/tweaking-sso-inconsistencies/131643
**Category:** Feature
**Created:** [22. Oktober 2019 um 15:16 UTC](https://meta.discourse.org/t/tweaking-sso-inconsistencies/131643 "2019-10-22T15:16:14Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![mentalstring](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mentalstring/32/168934_2.png) [@mentalstring](https://meta.discourse.org/u/mentalstring)
#### Post date: [22. Oktober 2019 um 15:16 UTC](https://meta.discourse.org/t/tweaking-sso-inconsistencies/131643/1 "2019-10-22T15:16:14Z")

</div>

Die meisten Profilfelder können bereits während des SSO-Prozesses festgelegt werden, was super nützlich ist. Vom Benutzernamen über den Namen und die Bio bis hin zur Website – die [wurde im vergangenen Jahr hinzugefügt](https://github.com/discourse/discourse/commit/4644d777bd7bb849adcfd6d04ebfb2542aff60c9). Es gibt jedoch noch einige kleinere Unzulänglichkeiten:

- `location` scheint zu fehlen – bei einem flüchtigen Blick ist dies das einzige offensichtliche Feld, das sich über SSO nicht ändern lässt.
- `website` kann zwar während des SSO-Prozesses angegeben werden, aber im Gegensatz zu den meisten (vielleicht allen?) anderen SSO-Profilfeldern gibt es keine entsprechende Site-Einstellung, die es erlaubt, den lokalen Wert zu überschreiben und zu verhindern, dass der Benutzer ihn ändert.

Ich vermute, dass diese Punkte einfach übersehen wurden, als die Codebasis im Laufe der Zeit wuchs, da mir kein Grund für diese Ausnahmen einfällt. Leider sind meine Ruby- und Discourse-Kenntnisse nicht ausreichend, um einen PR einzureichen, aber ich wollte den Fehler melden – vielleicht hat jemand die technischen Fähigkeiten, das zu beheben.

---

<div class="post-metadata">

### Author: ![mentalstring](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mentalstring/32/168934_2.png) [@mentalstring](https://meta.discourse.org/u/mentalstring)
#### Post date: [16. April 2020 um 14:46 UTC](https://meta.discourse.org/t/tweaking-sso-inconsistencies/131643/2 "2020-04-16T14:46:50Z")

</div>

Ich habe die Änderungen [umgesetzt](https://github.com/mentalstring/discourse/commits/sso-fields), um die beiden oben genannten Punkte zum Laufen zu bringen. Ich würde mich freuen, sie wieder in Discourse einzubringen, aber ich weiß nicht, ob es Interesse daran gibt, diese Änderungen upstream aufzunehmen? /cc @sam

Lass mich bitte Bescheid geben, bevor ich mich durch die Hürden des PR-Einreichungsprozesses kämpfe. Der Code funktioniert, muss aber möglicherweise überarbeitet werden, da ich neu bei Discourse bin.

---

<div class="post-metadata">

### Author: ![riking](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/riking/32/170938_2.png) [@riking](https://meta.discourse.org/u/riking)
#### Post date: [16. April 2020 um 19:23 UTC](https://meta.discourse.org/t/tweaking-sso-inconsistencies/131643/3 "2020-04-16T19:23:41Z")

</div>

Starte den PR, damit du den CLA-Prozess durchlaufen kannst, aber:

> [@mentalstring](#):
>
> `website` kann bei SSO angegeben werden, hat aber – im Gegensatz zu den meisten (allen?) anderen SSO-Profilfeldern – keine entsprechende Site-Einstellung, um den lokalen Wert zu überschreiben und zu verhindern, dass der Benutzer ihn ändert.

Das scheint nicht wirklich den Aufwand wert zu sein – andere Felder auf dieser Seite, wie z. B. das Hintergrundbild der Benutzerkarte, sind in SSO-Plattformen ohnehin nicht verfügbar, sodass es keinen Konsistenzvorteil bringt, eine Sperre für die Website einzuführen.

---

<div class="post-metadata">

### Author: ![mentalstring](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mentalstring/32/168934_2.png) [@mentalstring](https://meta.discourse.org/u/mentalstring)
#### Post date: [17. April 2020 um 13:53 UTC](https://meta.discourse.org/t/tweaking-sso-inconsistencies/131643/4 "2020-04-17T13:53:49Z")

</div>

> [@riking](#):
>
> Das fühlt sich nicht wirklich als sinnvoll an, sich damit zu befassen – andere Felder auf dieser Seite, wie das Hintergrundbild der Benutzerkarte, werden auf SSO-Plattformen ohnehin nicht verfügbar sein, sodass es keinen Vorteil in Bezug auf Konsistenz bringt, eine Sperre für die Website einzuführen.

Entschuldigung, ich bin mir nicht sicher, ob ich das richtig verstanden habe. Ich stimme zu, dass das Hintergrundbild der Karte auf SSO nur begrenzt nützlich ist (obwohl dies bereits implementiert ist). `website` ist ebenfalls ein bereits implementiertes SSO-Feld – ich habe lediglich eine Einstellung namens `sso_overrides_website` hinzugefügt, ähnlich wie es sie bereits für Benutzername, Avatar, Biografie usw. gibt, um lokale Änderungen zu unterbinden und den SSO-Wert vorrangig zu behandeln.
