Anforderungen an die SaaS Anwendung
- Die Anwendung soll in Docker laufen und deployed werden
- Präferenz MariaDB als Datenbank
MVP I
Registrierung
- Die Nutzerregistrierung soll aktiviert sein
- Nutzer hat einen Nutzernamen (lediglich buchstaben, keine sonderzeichen, zahlen)
- Email muss angeben werden
- Passwort wird angegeben
Login
- Eine Login Möglichkeit (Nutzername, Passwort) existiert
Profilseite
- Eine Profilseite existiert
- Passwort kann geändert werden
- Nutzername ist unveränderlich
Admin
- Übersichtsseite existiert
- Nutzer müssen durch einen Administrator freigeschaltet werden
MVP II
Schnittstelle
Kontext
Im folgenden geht es darum, dass pro Anwendung CRUD Befehle auf die LDAP Datenbank und ggf. auf die Anwendungen ausgeführt werden können. Über die SaaS Anwendung, soll ein einheitliches Anwendungsübergreifendes Nutzermanagement erfolgen.
Schnittstellendateien
Eine Schnittstelle besteht aus folgenden dateien:
Datei | Beschreibung |
---|---|
README.md | Platz zur Dokumentation |
meta.yml | Enthält, die parameter, anzeige und rechtedefinitionen |
create.py | Script das einen Nutzer in der Applikation anlegt |
read.py | Script das Nutzerattribute aus einer Anwendung ausliest |
update.py | Script das einen Nutzer in der Applikation updated |
create.py | Script das einen Nutzer in der Applikation löscht |
Beispiel
wordpress/
├── README.md
├── meta.yml
├── create.py
├── read.py
└── update.py
nextcloud/
├── README.md
├── meta.yml
├── create.py
├── read.py
└── update.py
mailu/
├── README.md
├── meta.yml
├── create.py
├── read.py
└── update.py
matrix/
├── README.md
├── meta.yml
├── create.py
├── read.py
└── update.py
meta.yml
Jede Schnittstelle soll über einen YAML file definiert werden (z.B. ein yaml file für nextcloud, wordpress, etc.) um zu gewährleisten, welche parameter abgefragt und angezeit werden sollen
username:
field:
type: string
name: user_name # Variablenwert der von den python scripten und zur forms generierung verendet wird
label: User Name
# More attributs to define the field, restrictions etc.
permissions:
create: # Administratoren und Moderatoren können Nutzer anlegen
- administrators
- moderators
read: all # Alle können den Nutzernamen einer Anwendung auslesen
update: none # Nutzername ist unveränderlich
delete: none # Nutzername kann nicht gelöscht werden
storage_space:
field:
type: int
label: Storage Space
name: storage_space
unit: Byte
permission:
create: # Administratoren und Moderatoren können Nutzer anlegen
- administrators
- moderators
read: user # Nur der Nutzer selbst kann seinen Nutzernamen auslesen
update: # Speicherplatz kann nur von Administratoren und Moderatoren angepasst werden
- administrator
- moderators
delete: none # Löschen des wertes nicht möglich
# ... Weitere Attribute
Die Idee ist aus diesen werten die anzeige im Frontend rollenabhängig für
- Administratoren
- Moderatoren
- User
zu generieren.
python scripte
Die felder die hier abgefragt werden sollen dann als json an python scripte übergeben welche die Manipulation an den LDAP einträgen und in den Einzelanwendungen vornehmen.
Beispiel
python update.py <<json>>
Die Python Scripte müssen pro Rolle definiert werden. Deswegen muss diese Schnittstelle so flexibel gehandhabt werden.
MVP II
Registrierung
- Registrierungs via Double Opt In via Email
- Einstellung ob registrierung möglich ist oder nur durch admin
Nutzermanagement
Die Schnittstellen aus MVP II sollen im Frontend angezeigt werden
MVP III
Voucher
- Ein Voucher soll bei der Registrierung eingegeben werden können.
- Je nach Voucher nutzer mit den zu den voucher passenden rechten angelegt z.B. Storage space
- Es soll implementiert werden, dass ein konfigurationsparameter registration existiert. Valide Werte: deactivated, with_voucher, open_for_everybody
- Business Case: Brauchen das zur Werbung am Anfang
MVP IV
Bezahlsystem
- Ein Bezahlsystem wird implementiert