Lorawan-stack: Einführung einer neuen Konto-App (als Ersatz für die oauth-App)

Referenzen https://github.com/TheThingsIndustries/lorawan-stack/issues/1659

In Bezug auf das gesamte Problem der Anmeldung/Abmeldung zwischen Konsole und Oauth-Anbieter ist hier mein Plan:

• Wir verwenden ein separates Account Logo für die Konto-App (anstelle des TTS-Logos) und verwenden dieselbe Header-Komponente, die wir auch für die Konsole verwenden (cc @pierreph)
• Anstatt zwei separate Anmeldebildschirme für die Konsole und die Konto-App zu haben, sollten wir die Erfahrung enger miteinander verbinden, d. h
  
  
  
  • Wir werden den Konsolen-Anmeldebildschirm /console/login entfernen
  
  
  • Die Konsole leitet automatisch zur Anmeldeseite der Konto-App /account/login , wenn sie kein (gültiges) Zugriffstoken hat
  
  
  • Wie bereits beim Konsolen-Login-Button verwenden wir einen Umleitungs-Abfrageparameter, um den Benutzer nach erfolgreicher Anmeldung zurück zur Konsole zu schicken
  
  
  • Das Abmelden von der Konsolen-Benutzeroberfläche führt zum Entfernen des gespeicherten Zugriffstokens sowie zum Abmelden von der Konto-App. Auf diese Weise müssen Benutzer ihre Anmeldeinformationen immer erneut eingeben, um sich wieder bei der Konsole anzumelden.
    
    
    
    
    
    • Um dies tun zu können, benötigen wir eine Möglichkeit, Abmeldungen von Cross-Origin-Anfragen auszulösen (da Konsole und Konto-App nicht garantiert denselben Ursprung haben)
    
    
    
    • In v2 verwenden wir eine einfache /users/logout Route, die eine Abmeldung auslöst, auf die von überall verwiesen werden kann
    
    
    
    • Es wäre gut, nach Wegen zu suchen, um dasselbe zu erreichen und gleichzeitig die Sicherheit der CSRF zu gewährleisten
    
    
    
  
  
  • Der neue Ablauf wird dem Ablauf der v2-Konsole ziemlich ähnlich sein; Wir werden im Grunde die Trennung von Konsolen-Client und Autorisierungsserver opfern, um die UX zu verbessern, was in Ordnung ist, da die Konsole eine Art Sonderfall-Client ist
  
  
  • Wir müssen diesen Ablauf möglicherweise überarbeiten, wenn wir in Zukunft andere Anmeldeverfahren zulassen
  
  

Wenn ich keine Beschwerden über diesen Plan höre, werde ich mit der Umsetzung beginnen.

Klingt nach einem tollen Plan. Ich stimme zu, dass wir keine explizite Abmeldung von der Konsole benötigen und über OAuth in der UX angemeldet bleiben, obwohl es unten so funktioniert.

Was benötigen Sie für die ursprungsübergreifende Abmeldung? Wäre es nicht ein einfacher zweistufiger Ansatz; Abmelden "Seite", um das in der Konsole gespeicherte Zugriffstoken zu entfernen, und dann zur generischen Abmeldeseite umzuleiten, auf der sich die Konto-App abmeldet? Oder möchten Sie dies ohne Umleitung, aber an einem Abmelde-Endpunkt posten?

Zum Abmelden können wir uns von OpenID Connect Logout inspirieren lassen. Schöne Zusammenfassung findet ihr hier: https://medium.com/@robert.broeckelmann/openid -connect-logout-eccc73df758f

Klingt nach einem tollen Plan. Ich stimme zu, dass wir keine explizite Abmeldung von der Konsole benötigen und über OAuth in der UX angemeldet bleiben, obwohl es unten so funktioniert.

Was benötigen Sie für die ursprungsübergreifende Abmeldung? Wäre es nicht ein einfacher zweistufiger Ansatz; Abmelden "Seite", um das in der Konsole gespeicherte Zugriffstoken zu entfernen, und dann zur generischen Abmeldeseite umzuleiten, auf der sich die Konto-App abmeldet? Oder möchten Sie dies ohne Umleitung, aber an einem Abmelde-Endpunkt posten?

Zweistufiger Ansatz ist in Ordnung. Meine Sorge war, dass das Abmelden der Konto-App CSRF deaktiviert werden muss, was bedeutet, dass jeder mit einem Abmeldelink jemanden dazu verleiten könnte, sich von seinem Konto abzumelden. Dies ist derzeit auch mit dem v2-Stack möglich ( hier klicken wird Sie abmelden ).
Ich denke, dies ist im Moment akzeptabel, aber nicht gerade die beste Vorgehensweise.

Ich habe jetzt einiges an Arbeit für die neue Konto-App geleistet:

• Überarbeitete Komponenten und Container, die von Konsolen- und Konto-Apps verwendet werden können
• Implementierte neue Designs (einschließlich Reaktionsfähigkeit)
• Implementierte Profileinstellungen, einschließlich Profilbild
• Berechtigungsmanagement implementiert (einsehen und widerrufen)
• Implementierte Sitzungsverwaltung (Anzeigen und Widerrufen)
• Beheben eines Problems, das zu leeren Renderings führte, wenn Abhängigkeiten von freigegebenen CSS-Modulen verwendet wurden

Ich tat dies, indem ich ein Zugriffstoken hartcodierte, um die Stack-API verwenden zu können. Ich bin derzeit nicht in der Lage, mit einer ordnungsgemäßen Implementierung voranzukommen, da ich nicht weiß, wie ich am besten ein Zugriffstoken für die Konto-App erhalten könnte.
Im Moment ist die "Oauth-App" nur eine SPA, die eine Verbindung zu den Authentifizierungsendpunkten des Oauth-Servers herstellt (Anmeldung, Abmeldung und andere kontobezogene Endpunkte, die kein Zugriffstoken benötigen).
@htdvisser hat mir

• Abhängig von der Quelle wird von der Art der Passworterteilung abgeraten, selbst für "offizielle" und vertrauenswürdige Kunden
• es würde einen weiteren Login-Bildschirm erfordern (neben dem Login-Bildschirm des Oauth-Anbieters)
• Ich frage mich, ob es eine Möglichkeit gibt, ein Zugriffstoken direkt vom Oauth-Anbieter zu erhalten, ohne einen anderen separaten Client verwenden zu müssen, da wir bereits die Authentifizierung in der Oauth-App durchführen
• Wenn wir die Passworterteilung für die Konto-App verwenden, sollten wir sie auch für die Konsole verwenden

Ich habe @htdvisser bereits gesagt, dass der gesamte Aspekt der delegierten Authentifizierung / Autorisierung für mich etwas überwältigend ist und ich mich nicht sachkundig genug fühle, um für eine so sicherheitskritische Angelegenheit verantwortlich zu sein.

Was wir anstreben sollten, ist ein Ablauf, der den Authentifizierungsablauf unserer offiziellen Clients wie eine native Authentifizierung aussehen lässt (siehe auch meinen anderen Kommentar ), was bedeutet, dass Anmeldungen und Abmeldungen global sind und es keinen Unterschied zwischen dem authentifizierten Status der Clients und geben sollte der Autorisierungsanbieter.

Ich bräuchte also etwas Hilfe und Input, um mit der Konto-App fortzufahren. Wie können wir das koordinieren?

Abhängig von der Quelle wird von der Art der Passworterteilung abgeraten, selbst für "offizielle" und vertrauenswürdige Kunden

Ja, die Passwortvergabe darf nicht verwendet werden, siehe Spezifikation und Begründung hier: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section -3.4

Derzeit blockiert von #2148

Nachdem ich mich jetzt eine Weile damit beschäftigt habe, brauche ich wohl etwas Input.

Die ursprüngliche Idee der Konto-App bestand darin, die aktuelle oauth-App zu ersetzen und die Funktionalität in Richtung Profil- und Sitzungsverwaltung zu erweitern (siehe OP). Das Problem dabei ist, dass die App zur Implementierung einer solchen Funktionalität ein Zugriffstoken benötigt, was im Wesentlichen bedeutet, dass die Konto-App sowohl ein OAuth-Anbieter als auch ein Client ist.

Meine Idee war, einen neuen OAuth-Client ( account ) einzuführen und die Funktionalität im Frontend mit der aktuellen OAuth-App zu verschmelzen. Für den Benutzer sieht es so aus, als ob sowohl der OAuth-Anbieter (Anmelden, Registrieren, Konto validieren usw.) als auch der Konto-App-Client (Profileinstellungen, Sitzungsverwaltung, Berechtigungsverwaltung) ein und dieselbe Anwendung sind, während im Hintergrund ist eine technische Trennung zwischen dem OAuth-Provider und dem Client. Im Backend würde der Account-Client Teil des oauth Pakets. Frontend-technisch könnten wir beide Dinge auch als dieselbe App behandeln, indem wir denselben Einstiegspunkt verwenden ( account.js ).
Ebenso würde das Routing diese Überblendung widerspiegeln, zB:

• /account/login für die OAuth-Anmeldung [OAuth-Provider-Schicht]
• /account/register für die Benutzerregistrierung [OAuth-Anbieterschicht]
• /account/forgot-password für die Benutzerregistrierung [OAuth-Anbieterschicht]
• /account/client/login/ttn-stack für die Client-Anmeldung (Autorisierung) [OAuth-Client-Schicht]
• /account/client/oauth/callback um den Authentifizierungscode auszutauschen [OAuth Client Layer]
• /account Übersichtsseite des OAuth-Clients [OAuth-Client-Schicht]

Alternativ könnten wir beide Bedenken getrennt halten, den OAuth-Anbieter ( /oauth über pkg/oauth ) so belassen wie er ist und die Konto-App behandeln ( /account über pkg/account ) als eine völlig separate Sache, wie wir es mit der Konsole tun. Der OAuth-Provider wäre dann nur noch für Authentifizierungsangelegenheiten zuständig, einschließlich Autorisierung und Registrierung des Benutzerkontos, hätte aber keine eigene authentifizierte Ansicht, wie er es derzeit hat. Stattdessen wird nach der Anmeldung standardmäßig zur Konto-App weitergeleitet, die dann automatisch ein Token abruft.

Ich habe das Gefühl, dass die erste Lösung einige der Verwirrung vermeiden könnte, die wir derzeit in Bezug auf Authentifizierung und Kontoverwaltung haben, aber ich kann nicht vorhersehen, ob sie zu anderen Komplikationen führen könnte. Die zweite Lösung scheint sauberer zu sein, aber die Frage ist, wie die Trennung kommuniziert/gebrandmarkt wird. Sollen zB beide noch als "Account-App" kommuniziert werden? Oder sollten es die The Things Stack Single Sign On und The Things Stack Account Application ?

Bitte teilen Sie mir Ihre Meinung mit.

Hmm, einen Schritt zurück, was ist der Zweck, die Konto-App zu einem OAuth-Client zu machen? Welche Funktionalität über OAuth wollen wir da drin haben?

• Profileinstellungen (Name, E-Mail, Profilbild)
• Sitzungsverwaltung (überprüfen, widerrufen)
• Berechtigungsverwaltung (Prüfung, Widerruf)
• (Möglicherweise andere TTES-bezogene Metaeinstellungen in der Zukunft)

All dies erfordert einen Zugriffstoken, da nur so die jeweiligen RPCs autorisiert werden können.

Wir brauchen eine Trennung des OAuth-Providers – der extern sein kann, zum Beispiel „The Things Network Community“ – und der Benutzerverwaltung – bei der es um die Verwaltung von Feldern der in The Things Stack gespeicherten Benutzerentität geht, einschließlich der Punkte @kschiffer schrieb oben im Kommentar.

Unsere /api/v3/* Endpunkte akzeptieren keine Cookie-Authentifizierung, da sie CORS-fähig sind. Sie funktionieren nur mit API-Schlüsseln und Access Tokens.

• Profileinstellungen (Name, E-Mail, Profilbild)
• Sitzungsverwaltung (überprüfen, widerrufen)
• Berechtigungsverwaltung (Prüfung, Widerruf)
• (Möglicherweise andere TTES-bezogene Metaeinstellungen in der Zukunft)

All dies erfordert einen Zugriffstoken, da nur so die jeweiligen RPCs autorisiert werden können.

Wir könnten diese auch zu einem Teil der Konsole machen, aber das würde bedeuten, dass die Konsole die Bedenken in gewissem Maße vermischt. Ich könnte Situationen sehen, in denen es besser wäre, die Kontoverwaltung ohne den Overhead aller anderen Konsolenfunktionen durchzuführen, aber vielleicht übertreibe ich das ️.

Im Allgemeinen stellt sich die Frage, ob wir die Konsole nur als Werkzeug zur Verwaltung netzwerkbezogener Angelegenheiten sehen möchten. Wir können es entweder als Allzweck-Verwaltungsplattform für alle TTS-bezogenen Angelegenheiten öffnen oder wir können atomarer sein und bei der Trennung bleiben und verschiedene Apps/Clients für unterschiedliche Anliegen verwenden. Es ist eine strategische Frage. Ich sehe Fälle für beide.

Ich denke nicht, dass die Konsole (alle Konsolen, da es in jedem Cluster eine Konsole gibt) volle Rechte für den Benutzer haben sollte. Konsolen sollten nicht verwendet werden, um autorisierte OAuth-Clients, Sitzungen, primäre E-Mail-Adressen und Kontaktdaten zu verwalten. Eine dedizierte Benutzerverwaltungs-App (die Konto-App) ist viel besser.

In der Tat, guter Punkt. Dann kommt die Ausgangsfrage zurück .

Meine Meinung ist:

Gemischter Ansatz:

• Von einem Benutzer-POV weniger verwirrend (ein Ort für alle kontobezogenen Angelegenheiten)
• Einfacheres Branding / Kommunikation
• Entspricht dem ursprünglichen Plan der Konto-App
• Frontend-technisch brauchen wir keinen neuen Einstiegspunkt und damit separates Boilerplating
• Die Implementierung wird komplexer/unübersichtlicher (Konto-App ist OAuth-Provider und Client)

Getrennter Ansatz:

• Sauberere und konventionellere Umsetzung
• Konfiguration flexibler und übersichtlicher
• Führt neben der oauth-App eine neue App ein, die ein vernünftiges Branding und eine vernünftige Kommunikation erfordert
• Längere Builds (könnte marginal sein, nicht getestet) und mehr Assets

Ich tendiere zum Blended-Ansatz.

• Profileinstellungen (Name, E-Mail, Profilbild)
• Sitzungsverwaltung (überprüfen, widerrufen)
• Berechtigungsverwaltung (Prüfung, Widerruf)
• (Möglicherweise andere TTES-bezogene Metaeinstellungen in der Zukunft)

Dies ist eine Konto-App, oder? Kein OAuth?

• Führt neben der oauth-App eine neue App ein, die ein vernünftiges Branding und eine vernünftige Kommunikation erfordert

Wozu dient die OAuth-App dann noch?

Können Sie die Funktionen für den Benutzer auflisten, die der OAuth-Client der Konto-App hinzufügt, die wir nicht in die Konto-App einbauen können, möglicherweise über neue Endpunkte?

Dies ist eine Konto-App, oder? Kein OAuth?

Ja, dies ist eine Konto-App. Aber der Plan war, dass das, was wir derzeit als OAuth-App haben, Teil der Konto-App wird.

Wozu dient die OAuth-App dann noch?

Zur Authentifizierung (als Teil des OAuth-Flows), Benutzerregistrierung, Client-Autorisierung, Passwort-Reset. Im Grunde alles was mit Authentifizierung von Benutzern und Autorisierung von Clients zu tun hat.

Können Sie die Funktionen für den Benutzer auflisten, die der OAuth-Client der Konto-App hinzufügt, die wir nicht in die Konto-App einbauen können, möglicherweise über neue Endpunkte?

Das Problem ist eher umgekehrt, wir können unsere aktuelle OAuth-App nicht einfach um die Funktionalitäten erweitern, die wir für die Konto-App wünschen, da wir ein Zugriffstoken benötigen würden. Es ist ein bisschen ein Henne-Ei-Problem. Gäbe es für die Account-App-Funktionalitäten (Sitzungen, Autorisierungen usw.) eine andere Autorisierung, zB über das Sitzungs-Cookie, das die OAuth-App hat, dann wäre es anders. Aber so wie ich das sehe ist das nicht machbar.

Ist die OAuth-App eine eigenständige Sache? Implementiert es die Umleitungsabläufe für OAuth-Clients? Oder ist es selbst ein OAuth-Client?

Betonung von mir:

Meine Idee war, einen neuen OAuth-Client ( account ) einzuführen und die Funktionalität im Frontend mit der aktuellen OAuth-App zu verschmelzen. Für den Benutzer sieht es so aus, als ob sowohl der der Konto-App-Client (Profileinstellungen, Sitzungsverwaltung, Berechtigungsverwaltung) ein und dieselbe Anwendung sind, während im Hintergrund ist eine technische Trennung zwischen dem OAuth-Provider und dem Client . Im Backend würde der Account-Client Teil des oauth Pakets .

Ich sehe hier;

• OAuth-Client
• aktuelle OAuth-App
• OAuth-Anbieter
• der Konto-App-Client
• der OAuth-Anbieter
• der Kunde
• das Backend
• der Kontokunde
• das oauth Paket

Ich versuche, den Vorschlag zu verstehen, aber ich verstehe nicht ganz, was noch ist.

Was sind also die Funktionen, die wir wollen?

1. Benutzerkonto erstellen
2. Passwort vergessen
3. Anmeldung
4. Kennwort ändern
5. Profil anzeigen und bearbeiten
6. Sitzungen verwalten
7. OAuth-Zeug
   
   
   
   1. Zustimmungsbildschirm (OAuth-Autorisierungscodefluss)
   
   
   2. OAuth-Autorisierungen verwalten
   
   

Ich denke, dass 1-6 implementiert werden kann, ohne OAuth zu berühren, wenn wir mit Sitzungsauthentifizierung gehen. Das ist möglich, oder?

Ja entschuldigung. Wir haben hier eine Reihe von unfixierten Begriffen, die es ziemlich schwierig machen, Dinge zu erklären. Zumindest gibt es einen guten Einblick in die Komplexität des Themas 😅.

Nehmen wir also den Status Quo:

OAuth-Anbieter
Die Entität, die die Autorisierung (und in unserem Fall auch die Authentifizierung) gemäß der OAuth 2.0-Spezifikation bereitstellt. In unserem Fall ist das das Paket pkg/oauth , das wiederum die OAuth-App (siehe unten) verwendet, um die notwendige Benutzeroberfläche zum Abrufen von Benutzerinformationen (Render-Login, Registrierung, Autorisierungsansichten usw.) zu implementieren.

OAuth-App
Dies ist die Reaktions-Webanwendung auf dem Frontend. Unser Frontend-Code besteht aus verschiedenen Apps (mit verschiedenen Einstiegspunkten oauth.js / console.js ), die gemeinsame Teile wie Reaktionskomponenten und Dienstprogramme teilen

OAuth-Client
Ein registrierter Client, der OAuth zur Authentifizierung und Autorisierung verwendet, wie die Konsole oder CLI.

oAuth-Paket
Das Go-Paket, das für die Implementierung des OAuth-Anbieters verantwortlich ist. Das sind pkg/oauth .

Sie sehen also, hier spielen drei oder vier verschiedene Schichten eine Rolle. Das Problem ist, dass wir, wenn wir die Autorisierung im Moment beibehalten, etwas haben müssen, das alle oben beschriebenen Rollen gleichzeitig spielt.

Ich denke, dass 1-6 implementiert werden kann, ohne OAuth zu berühren, wenn wir mit Sitzungsauthentifizierung gehen. Das ist möglich, oder?

Ja. 1-4 sind bereits ohne Oauth / Access Token möglich. 5 und 6 benötigen derzeit ein Zugriffstoken. 7. ii ist noch nicht implementiert. Wenn 5 und 6 ohne Zugriffstoken möglich wären, bräuchten wir dafür tatsächlich keinen weiteren Oauth-Client. Dennoch müssen wir bedenken, dass jede Funktionalität, die wir in Zukunft der Konto-App hinzufügen möchten, dann nicht den Zugriffstoken als alleiniges Autorisierungsinstrument verwenden darf.

Wenn 5 und 6 ohne Zugriffstoken möglich wären, bräuchten wir dafür tatsächlich keinen weiteren Oauth-Client. Dennoch müssen wir bedenken, dass jede Funktionalität, die wir in Zukunft der Konto-App hinzufügen möchten, dann nicht den Zugriffstoken als alleiniges Autorisierungsinstrument verwenden darf.

Richtig. Das macht für mich sehr viel Sinn. Dies ist auch eine bessere Grundlage für den "Sudo-Modus", in dem Benutzer Dinge _nur_ in der Konto-App tun können, nachdem sie beispielsweise Ihr Passwort erneut eingegeben haben. Also ja, es könnte einige Überschneidungen zwischen den Möglichkeiten von OAuth-Clients und der Konto-App geben, aber diese Überschneidung scheint mir nicht groß zu sein. Ich sehe den Wert darin, Dinge der Konto-App zu widmen.

Okay klingt gut.
@htdvisser Haben Sie Einwände? Und wenn nicht, können Sie mich auf die entsprechenden Dateien/Pakete zur Autorisierung hinweisen, da Sie wahrscheinlich in nächster Zeit keine Zeit haben werden, daran zu arbeiten (?).

Wie ich bereits erwähnt habe, akzeptieren unsere /api/v3/* Endpunkte keine Cookie-Authentifizierung, da sie CORS-fähig sind. Wenn Sie die Cookie-Authentifizierung akzeptieren möchten, müssen Sie sich unsere CORS-Header genau ansehen, da wir wirklich nicht möchten, dass ein Angreifer Cookie-authentifizierte ursprungsübergreifende Anfragen an diese Endpunkte stellt.

Unsere API besteht ausschließlich aus gRPC, und die Authentifizierung erfolgt mit dem Authorization Header, der als Anfragemetadaten an gRPC weitergegeben wird. Die Implementierung der Session-Authentifizierung könnte wie folgt aussehen:

• Fügen Sie einen SessionToken Typ zu pkg/auth/auth.go
• Fügen Sie dem Session Modell einen geheimen Teil hinzu, ähnlich wie wir es mit API-Schlüsseln und Zugriffstoken tun.
• Fügen Sie eine Middleware hinzu, die die Sitzungs-ID und das Sitzungsgeheimnis aus dem Cookie extrahiert und als SessionToken an den Authorization Header weiterleitet
• SessionToken als case zu switch tokenType { in pkg/identityserver/entity_access.go

Hierbei ist zu beachten, dass dies auch bedeutet, dass die Konto-App und die v3-API von derselben Quelle bedient werden müssen. Andernfalls würde die Cookie-Authentifizierung nicht funktionieren, da der Authentifizierungskontext verschiedene Ursprünge umfasst.
Ich bin mir nicht sicher, wie akzeptabel das ist. Zumindest in der Praxis scheinen wir in unseren Bereitstellungen die gleichen Ursprünge zu verwenden.

Ja, sie werden denselben Ursprung haben.

@kschiffer bitte freigeben können.

Eine Zusammenfassung habe ich hier geschrieben: https://github.com/TheThingsNetwork/lorawan-stack/pull/2850#issuecomment -657497193

OK, lassen Sie uns das Gespräch hier fortsetzen.

@kschiffer Nachdem

• Der Frontend-Teil der oauth-App würde im Grunde nur aus dem Autorisierungsbildschirm bestehen

ja

• Ich finde es sehr ärgerlich, die is.oauth.ui.* Configs nur dafür behalten zu müssen
  […]
• Ich bin mir auch ein wenig unsicher über die genauen Einschränkungen, wie wir die Stack-Konfiguration ändern können, ohne den CC zu beschädigen
• Ich habe ein bisschen Pech, hier eine praktikable Lösung zu finden und brauche wirklich etwas Input

Wir können die Konfiguration in V3 nicht unterbrechen, aber wir können eine neue Konfiguration einführen, die alte Konfiguration verwerfen, die alte Konfiguration als Fallback verwenden und ein TODO-Problem mit der Bezeichnung bump/major einreichen, um die alte Konfiguration zu entfernen.

Mein Vorschlag wäre also, eine neue Konfiguration einzuführen, die einen vollständigen Ersatz darstellt und die neue Konto-App aktiviert. Aus Gründen der Abwärtskompatibilität sollte es funktionieren, ohne dass der Benutzer diese neue Konfiguration angibt, dh sich auf vernünftige Standardwerte und alte Konfiguration über is.oauth.ui.* .

@kschiffer wie ist hier der Status?

Derzeit rebasiert meine Arbeit am neuen Gerüst, die hier läuft: #3453

Als nächstes geht es darum, die authentifizierten Ansichten umzubasieren, zu reparieren und zu PRen und die aktuellen Designs an das neue Branding anzupassen.

@kschiffer wie ist hier der Status?

Die Konto-App wurde in 3.11 eingeführt. Aktuell fehlen noch:

• Kontowechsel #488
• Sitzungsverwaltung
• Berechtigungsverwaltung (hierzu gehört auch das Hinzufügen von API-Endpunkten)

OK. https://github.com/TheThingsNetwork/lorawan-stack/issues/488 scheint bereits geschlossen zu sein.

Dies war ein großes Problem. Können Sie ein oder zwei neue Probleme für die oben genannten einreichen, um diese zu ersetzen, damit sie geschlossen werden kann?