feat: ui oauth integration #21266
feat: ui oauth integration #21266
Conversation
|
Persönlich tendiere ich zu 1, auch weil man keinen zusätzlichen Login Button braucht, der nur manchmal da ist:
Falls ein vorhandenes Vehicle editiert wird, kann ein zusätzlicher Logout Button angezeigt werden. |
|
Haben wir eine Datenabhängigkeit von Nutzereingaben (bspw. VIN, ...) zu des Login Buttons? Also, dass wir die richtige URL erst dann erzeugen können, wenn der Nutzer bestimmte Felder ausgefüllt hat? Generell würde ich Variante 2 bevorzugen. Also ein Login/Logout Button, sofern erforderlich. Den aktuelle Status des Auth-Vorgangs und Logout müssen wir auf der Seite ja ohnehin anzeigen. Die "Test"-Funktion würde ich unabhängig davon sehen. Aus Nutzersicht kann es unerwartet sein, dass ein Klick auf Test oder Speichern zu einem Absprung nach Außen führt. Beim Klick auf einen "Anmelden" (o.ä.) Button würde man so etwas ja durchaus erwarten. Spannend ist ja auch der Rücksprung ins Config UI. Hier müssten wir dem Nutzer ja das, ggf. noch nicht gespeicherte, Formular/Modal wieder anzeigen. |
|
Ja, Datenabhängigkeit besteht, zumindest bei Volvo. Bei anderen APIs sind die Oauth Einstellungen fest. Einfachste Lösung, die mir einfällt, ist im Template einen Switch |
Könnten wir ja auch über einen Redirect über uns selbst spielen - zusammen mit den Nutzer-Eingaben als Params. Datenabhängigkeit: wir könnten den neuen "Login" Button, genau wie Test und Save, auch an die Validity des Forms koppeln. Also de-facto gleiche Signatur/Verhalten wie der Test-Endpunkt nur mit einer dedizierten Aufgabe: Starten des OAuth-Flows. |
|
gerade leider wenig Zeit hieran weiterzuarbeiten. Ganz interessant ist die Herangehensweise von HomeAssistant bzgl OAuth: https://www.home-assistant.io/integrations/application_credentials/ (als Orientierung) |
FollowUp für #21003
Ziel: Login/Logout via OAuth irgendwie in die UI zu integrieren.
Möglichkeiten: