Vlt. kann mir jemand von euch auf die Sprünge helfen, da Ich die OIDC geschichte in LWS nicht so ganz durchschaue.
Wie bzw. wo kann Ich verwalten, wer auf die unterschiedlichen Addons zugriff hat?
Bzw. anders gesagt, grundsätzlich haben immer alle user zugriff auf alle Addons (wenn sie den Pfad kennen) und Ich muss innerhalb der Addons die zugriffe regeln?
Im Portal kann Ich ja in dem sinne nur die links deaktivieren, dass hat aber keine Auswirkungen auf den zugriff.
Und in der Benutzerverwaltung habe Ich keine Möglichkeiten Dienste freizugeben oder zu sperren?
Du kannst Gruppen anlegen, den Mitgliedern die entsprechenden Gruppen geben und nur die Mitglieder entsprechender Gruppen sehen dann die addons. Wie es aber gehandhabt ist, dass die Addons nur für die Gruppen aufrufbar sind welche zugeordnet wurden weiß ich leider nicht.
So in etwa hab Ich das auch verstanden, aber wenn jemand die URL kennt und sich vorher im Portal anmeldet hat er ganz normalen Zugang.
Im Portal wird ja “nur” der link deaktiviert.
Ich kenn das von PocketID, dass Ich jede App einzeln konfigurieren kann und den Zugang dadurch auch evtl. komplett verwehre.
Das hab Ich aber so innerhalb von LWS nicht gefunden.
Wenn die App es unterstützt das mit Gruppen innerhalb der App gearbeitet werden kann sollte das eigentlich funktionieren, dass nur die Personengruppe Zugriff drauf hat. Sicher bin ich mir aber nicht.
Erstelle mal ein Issue im repo auf Codeberg, dass nur Gruppen auf Apps zugreifen dürfen egal ob der link bekannt ist oder nicht.
Leider funktioniert das nur im Dashboard. Beim direkten Aufruf der Subdomains ist ein Zugriff dann trotzdem möglich. Für mich ist das allerdings ein wichtiges Feature, da ich nicht möchte, dass alle User alle Apps verwenden können.
Zum Glück ist das mit nicht großen Aufwand zu implementieren. Verwendet wird der django-oidc-provider, der gut dokumentiert ist. Ich habe mich dabei von ChatGPT beraten lassen; eine der vorgeschlagenen Lösungen erschien mir sinnvoll: für die Authorisierung wird ein Authorize-Request ausgeführt - dieser wird zunächst an eine eigene Funktion umgeleitet, die überprüft, ob die Gruppenzugehörigkeit passt und im positiven Falle den Request an die Originalfunktion weiterleitet oder ansonsten ablehnt.
Das habe ich dann für meine Installation testweise selbst umgesetzt; für die Programmierung habe ich im Wesentlichen die Funktionalität aus dem App-Dashboard übernommen. Bei mir funktioniert das soweit ganz ordentlich, bin aber noch am Testen.
Den Code dafür kann ich ggf. zur Verfügung stellen, falls dies auch von den Autoren erwünscht ist.
Nachdem Ich nun doch einige Erfahrungen gemacht habe hat sich das Gesamtbild nun auch ein wenig zurecht gerückt. Durch die Übergabe der Gruppen hat man in den meisten fällen die Möglichkeit Einschränkungen zu setzen. vorausgesetzt die Zielsoftware unterstützt das (z.B. Bookstack, Nextcloud, …). Wenn man die Gruppen oder Nutzerrechte dann in jeder einzelnen Software korrekt setzt passt das weitestgehend. Was mir dennoch fehlt ist die möglichkeit eine Gruppe komplett NICHT zu übergeben.
Für Zielsoftware ohne User Management wie StirlingPDF (in der Free Version), bei der mir aber die rechte an sich egal sind, hab Ich TinyAuth dazwischen geschaltet um den Zugriff von außen auf Portal Nutzer zu beschränken, das klappt recht gut. Hier gibt es auch die möglichkeit gruppen durchzureichen, da bin Ich derzeit in verbindung mit frigate am testen
