Webseite für Klassentreffen

lano

lano

Aktives Mitglied
Moin.

Ich hab da mal ne Frage.
Zwecks Klassentreffen würde ich gern eine Webseite erstellen.
Das soll dazu dienen die Leute zusammen zu sammeln und soll die Möglichkeit bieten privat Nachrichten zu verschicken sowie sone Art mini Forum.
Man soll halt nen thema erstellen können und alle anderen sollen dann dazu kommentare hinterlassen können.

ok, eigentlich sind es zwei fragen.

erste. die privatnachrichten würde ich gern verschlüsseln.
ich selbst als admin soll da nicht dran kommen können.
mir ist nicht ganz klar was für wege es da gibt und was sinnig wäre.

zweite. ich würde gern nen einladungslink per browser api verschicken können.
das soll im grunde so...
ich erstelle eine datenbank und lege die user anhand ner alten klassenliste an.
wenn man jetzt zb jemanden findet irgendwo, realität, facebook und wie sie alle heißen. dann soll man die person auswählen können aus ner optionsliste.
und den generierten link verschicken. wenn der link aufgerufen wird kann man nen password vergeben und gut.
wie mach ich das am simpelsten mit sonen links.
ok nicht ganz die frage für js...
generiere ich nen link und speicher den dann in der datenbank quasi als einladung, max mustermann hat am x uschi eingeladen?
würde ja sinn machen nen link ala example.com/class.php?invitation=<md5> zu erstellen das sich nicht direkt jeder anmelden kann.
bin ich son bischen planlos.
 
Alles nicht so ganz JS-spezifisch, aber für das Forum würde ich eine fertige Lösung benutzen. Mir fallen im Forum-Bereich bei klein, erweiterbar und kostenlos grad nur Discourse (Ruby?) und Flarum (PHP?) ein. Ich weiß nicht, ob es noch PhpBBForum gibt, ich glaube das war auch kostenlos. Für JS gibt es bestimmt auch so Einiges.

Einladungen per Link oder Mail müssten jedenfalls alle unterstützen. Private Nachrichten müssten die auch haben, aber bin mir nicht sicher. Und Berechtigung zum Einladen kann auch an User vergeben werden.

Private Nachrichten und Verschlüsselung​

Wie gesagt bin ich mir nicht sicher ob diese Lösungen User-verschlüsselte, private Nachrichten unterstützen.

Wenn der Server die Nachrichten nicht entschlüsseln können darf, muss die Entschlüsselung komplett clientseitig stattfinden. Der User muss das Geheimnis bei sich herumliegen haben und jeder Nachrichtenteilnehmer muss wissen, mit welchem Geheimnis Nachrichten an den Empfänger verschlüsselt werden sollen. Sowas würde man normalerweise über asymmetrische Verschlüsselung durch private und öffentliche Schlüssel machen, damit nicht für jede mögliche User-Kombination ein neues Geheimnis erstellt werden muss. Der Server könnte mit den öffentlichen Schlüsseln jonglieren, damit der User das nicht machen muss. Aber dieser müsste trotzdem noch seinen eigenen privaten Schlüssel verwalten. Und ohne Hilfsmittel wird das nix mit Ottonormalbenutzern! 🤷‍♂️

Wenn ich für diesen Fall Verschlüsselung von Nachrichten selber bauen müsste, würde ich das ganz naiv über die PWs der Nachrichtenempfänger + deinem Salt verschlüsseln (oder durch SingleSignOn). Dann sind halt alle Nachrichten doppelt vorhanden. Wenn der User sich einloggt, werden die Nachrichten entschlüsselt und lokal im Browser gespeichert. Jegliche PW-Änderung dürften dann nur durch den User erfolgen, da die alten Nachrichten sonst nicht mehr entschlüsselt werden können. Und bei einem vergessenen Passwort ist einfach alles weg, wenn es nicht im localstorage vom Browser zwischengespeichert war.

Nicht naiv betrachtet würde ich die Verschlüsselung auf keinen Fall selber implementieren, weil ich mir nicht zutraue, da keinen Fehler zu begehen. Ich würde User auf andere Lösungen umleiten: fertige Lösung vom Forum, Matrix-Protokoll usw.

Einladungslinks​

Ja genau. Ungefähr so wie du es dir vorstellst. Solche One-Time-Links werden in der DB hinterlegt, haben in der Regel ein Verfallsdatum oder maximale Lebensdauer und werden nach dem Verbrauch als "benutzt" markiert oder gelöscht. Sie können auch einem bestimmten Zweck zugeordnet werden. Ähnlich wird es auch bei Passwort-Reset-Links gemacht.

User einladen​


Es liest sich auch so, als würdest du gerne vorhandenen Usern ermöglichen, reservierte aber noch nicht registrierte User einzuladen. Bisschen untypisch, aber sollte sogar mit Fertiglösungen gehen. Wenn du das so rum machen willst, könntest du die vorhandene "Passwort-Vergessen"-Funktion ausnutzen: Vorhandene User bräuchten dann das Recht, eine E-Mail-Adresse für die reservierte Person vorzuschlagen. Dieses Event müsste dann ein PW-Vergessen-Vorgang für die vorgeschlagene Mail starten. Und wenn das klappt, dann wird die vorgeschlagene Mail übernommen und die Person wird als registriert statt nur reserviert gesetzt (könnte über Gruppen-Berechtigung geregelt werden).

Ich weiß jetzt nicht, wie groß das alles werden soll. Deswegen würde ich das einfach alles aus der Fertiglösung so lassen wie es ist. Eine Schulklasse ist nicht groß. Einfache Einladungslinks reichen doch aus und sie können dann ihre Echtnamen eintragen, um zu wissen, wer wer ist.


Selber machen​

Nur weil ich sage, dass ich das nicht selber machen würde, heißt das nicht, dass du das nicht gerne versuchen kannst. Wenn das alles in einem kleinen Kreis bleiben soll, dann klingt selber machen schon ganz gut und kann auch Spaß machen. Für größere Projekte wäre ich vorsichtig mit komplett selbstgebauten Lösungen.
 
Mat schrieb:
Aber dieser müsste trotzdem noch seinen eigenen privaten Schlüssel verwalten. Und ohne Hilfsmittel wird das nix mit Ottonormalbenutzern! 🤷‍♂️
Zum Vergrößern anklicken....
Ja das ist auch der Punkt wo ich nicht weiter komme. Wäre schön aber muss auch nicht.
Mat schrieb:
Es liest sich auch so, als würdest du gerne vorhandenen Usern ermöglichen, reservierte aber noch nicht registrierte User einzuladen.
Zum Vergrößern anklicken....
Ja genau.

Mat schrieb:
Ich weiß jetzt nicht, wie groß das alles werden soll.
Zum Vergrößern anklicken....
Das soll im grunde nur dazu dienen die leute wieder zusammen zu bekommen.

Ich hab mir gedacht das man einfach ne alte klassenliste nimmt und jeder der angemeldet ist kann infos zu einer person hinzufügen.
Forumsmäßig gehts halt um minimal geschichten. das jetzt nix wofür ich groß ne fertig lösung bräuchte.
das sind vllt ne handvoll themen. klassentreffen ja/nein. wisst ihr noch damals bla bla...
der richtige austausch untereinander wird wohl über andere kanäle stattfinden.

vorrangig geht es darum ne aktuelle liste aller leute zu erstellen und infos hinzufügen zu können.
bspw find ich einige auf facebook aber die sind schon zu recht lange nicht mehr aktiv dort.
also müsste man die leute anschreiben die in den freundes listen auftauchen und die irgendwelche beiträge geliked haben.
das man das halt nen bisschen sammeln kann und abarbeiten, so hab ich mir das gedacht.

ich denke selber machen ist das einfachste. das sollte alles recht überschaubar sein und eigentlich schnell gemacht.
 
Ja, ok, dann ein paar konkretere Ideen:

Private Nachrichten clientseitg entschlüsseln​

  1. jeder User hat einen Public Key und einen Private Key
  2. der Public Key ist unverschlüsselt in der DB gespeichert
  3. der Private Key ist, mit dem PW des users verschlüsselt, in der DB gespeichert
  4. schickt User A eine Nachricht an User B, wird diese mit dem öffentlichen Public Key von User B verschlüsselt
  5. eine Kopie der versendeten Nachricht wird, mit Public Key von User A verschlüsselt, bei User A abgespeichert
  6. Nachrichten liegen also alle nur verschlüsselt auf dem Server
  7. User B loggt sich ein (erfolgt Serverseitig durch Hashabgleich von PW)
  8. User B öffnet private Nachrichten
  9. verschlüsselte private Nachrichten werden in den localstorage des Browsers runtergeladen
  10. clientseitig: Private Key von User B im localstorage des Browsers gesucht
  11. clientseitig: falls Private Key nicht im localstoragedes Browsers liegt
    1. verschlüsselter Private Key von User B wird vom Server runtergeladen und im localstorage gespeichert
    2. PW wird erneut abgefragt
    3. Private Key wird im localstorage entschlüsselt und gespeichert
  12. clientseitig: Sammlung privater Nachrichten wird mit dem Private Key entschlüsselt
So in der Art müsste das klappen. Kann aber natürlich Denkfehler enthalten. Brauchst dann halt noch eine clientseitige JS-Komponente für die Entschlüsselung usw. Außerdem musst du aufpassen, dass nicht einfach jeder die Kommunikationsschnittstelle zwischen Client und Server benutzen kann, also müssen sich Client und Server gegenüber authentifizieren.

Die symmetrische Verschlüsselung des Private Key sollte nur den Key selbst betreffen (also den base64-Teil), und nicht den Header beinhalten. Damit Angreifer, die an Teile deiner DB kommen, nicht sofort sehen, dass der Private Key überhaupt verschlüsselt ist.

Den clientseitigen Teil könntest du vielleicht sogar über ein Browserplugin hinkriegen, wenn es da schon etwas in der Richtung gibt.

Usereinladungen​

Serviervorschlag für OTL (One-Time-Links)

Nützliche Felder könnten sein:
  1. Einladungs-ID: zufälliger Hash, möglichst lang, damit er nicht leicht erraten werden kann (8+ alphanumerische Zeichen)
  2. Eingeladener: id des eingeladenen Users
  3. Referrer: id des einladenden Users
  4. Verfallsdatum: zeitstempel oder Gültigkeitsdauer
  5. Erstellt am: zeitstempel oder datetime
  6. diverse Flags oder Feld mit Flag-IDs/enums, wie zB:
    1. "angenommen": Eingeladener hat sich registriert
    2. "ungültig": Link wurde irgendwo öffentlich gepostet und Admin hat ihn sicherheitshalber deaktiviert
Sobald ein User sich mit diesem Link registriert, sollte sein account umgewandelt werden in einen echten User.

Userdaten ergänzen​

Sobald ein User sich in deinem Forum registriert hat, sollte er, wie schon gesagt, als echter User zählen und nicht mehr als "gesucht". Dann sollten nur noch der User selbst und der Admin in der Lage sein, die Daten zu ergänzen.

Entweder hast du 1 Tabelle mit gesuchten Leuten und 1 Tabelle mit usern, oder du hast alles in einer Tabelle.

Ich würde getrennte Tabellen empfehlen. Bei Registrierung wird dann der User in der Gesuchten-Tabelle als registriert markiert und mit dem neuen Useraccount verknüpft. Der Datensatz ist dann schreibgeschützt. Der neu registrierte User wird mit möglichst vielen Daten aus der Gesuchten-Tabelle vorausgefüllt.
 
Also der Weg mit dem verschlüsselten Zertifikat hatte ich auch schon im Kopf und wieder verworfen.
die ganze geschichte wäre auf dem server ja nur so sicher wie die verschlüsselung des privat zertifikats.

ich kanns ja mal ausprobieren.
 
Ist ein Kompromiss, weil technisch nicht versierte User ihre PK verlegen oder unsicher aufbewahren würden. Besser wäre natürlich, komplett lokal zu speichern, sodass der Server nix vom PK weiß (für den Fall dass ein User ein leicht zu erratendes PW hat). Könnte man natürlich noch mit einem weiteren Schlüsselpaar zwischen Server und User verschlüsseln, aber das könnte unübersichtlich werden.

Vielleicht traue ich den Usern auch zu wenig zu. Browser Plugins wie Mailvelope machen sowas komplett lokal und viele User scheinen damit klar zu kommen.

Also könntest du auch die rein lokale Speicherung überlegen. Brauchst dann nur einen Prozess, der bei PK-Verlust das Zurücksetzen von Nachrichten übernimmt. Wenn die Nachrichten mal alle verloren gehen ist es wahrscheinlich eh nicht so schlimm.
 
Zurück
Oben Unten