@ChristianM : Ah, interessant. Da gibt es also Tücken. Danke für den Post.
"Dramatisch" finde ich das schon, es scheint mir eine Sicherheitslücke: ein User sieht Daten eines anderen ... und kann diese schlimstenfalls sogar ändern.
Ich durchblicke jedoch deine Situation noch nicht ganz. Du schreibst:
Ich habe nach erfolgreichen "Login" die MitgliederID in einer Session Variablen gepeichert und keinen erneuten "Login" vollzogen solange sie vorhanden ist.
Was genau meinst du mit dem zweiten Halbsatz?
- keinen neuen "Login" vollzogen = Session Variable MitgliederID nicht geändert (auch wenn beispielsweise vom Portal ein neues {{AccessSecrets}} gesendet wurde)?
- solange "sie" (?) vorhanden ist = solange eine MitgliederID in einer Session-Variablen gespeichert (=vorhanden), diese also nicht leer/undefined ist?
Dann wundert mich das von dir beobachtete Verhalten nicht. Denn da ist ja noch eine (die ALTE) MitgliederID in der (Browser-)Session-Variable vorhanden (weil Browser nicht geschlossen). Also macht dein Script (nach deinen Angaben) "kein neues Login", d.h. es prüft das {{AccessSecret}} nicht erneut, selbst wenn ein neues per iFrame vom Portal kommt (weil sich ja ein neuer User angemeldet hat). Somit verzichtet dein Script (absichtlich!?) auf diese leicht durchführbare Prüfung, ob der Portal-User sich verändert hat (erkennbar am geänderten AccessSecret).
Die einzige Möglichkeit, Änderungen am Portal-User mitzubekommen, ist ja, wenn das Portal deinem Script via der iFrame-Integration etwas "mitteilt" und (!) dein Script auch genau darauf reagiert! Ein anderer Kommunikationsweg vom Portal zu deinem Script (via iFrame-URL+GET-Parameter) existiert ja nicht (oder doch?).
Daher MUSS das Script, wenn es ein {{AccessSecret}} empfängt, dieses auch IMMER prüfen. Egal was sonst noch in Cookies / Session Variables gespeichert ist. Sonst ist doch die ganze Idee kompromittiert.
... oder ich habe nicht verstanden, was du meinst.
Im Grunde zeigt das hier, dass wir dasiFrame mit {{AccessSecret}} schon verbiegen, wenn nicht missbrauchen für eigentlich etwas anderes, nämlich ein EIGENES Mitglieder-Portal unter Nutzung der Webling-Portal-Credentials.
Das war ja weiter oben schon Thema. Leider kommen wir an die Webling-Credentials der User nicht dran. Daher der Umweg.
Und weiter:
Wenn man beispielsweise das iFrame "in einem neuen Browser-Fenster öffnet", kann man da ja auch bei interaktiven Scripten (forms, etc.) weitermachen, auch wenn man sich im Webling-Backend zwischenzeitlich abmeldet. Das "beweist" ja, dass wir hier ein zweites Portal kreieren.
Dessen "Logout" müssen wir selbst übernehmen, das kann das Webling-Portal nicht (solange es keinen "Portal-Logout-Hook" gibt).
Immerhin können wir (siehe oben) vermeiden, dass ein NEU ANGEMELDETER User die Daten eines anderen sehen (oder gar ändern) kann.
Für den alten User gilt: Bevor er vom Browser (PC, Phone, Tablet, etc.) weggeht, soll er alle Browser-Fenster mit sensiblen Inhalten schließen. Daran erinnert uns ja auch jedes Online-Banking-System. Gilt hier auch.
Ideen (auf die Schnelle):
- Timeout (wie beim Online-Banking). Auto-Logout nach xxx Sekunden/Minuten/Stunden Inaktivität. Dafür gibt es Standard-Lösungen (Cookies).
- bei GET/POST auf dem Server immer das alte {{AccessSecret}} (im hidden-input einer in der Vergangenheit erstellten HTML-Form) mit dem aktuellen (aus Session-Storage/Cookie) vergleichen, so kann man unerlaubte Schreib-Zugriffe nach Portal-Ummeldung erkennen ... und dann einfach nicht zulassen. Das heißt auch: kein GET/POST ohne AccessSecret als GET/POST-Parameter! Sonst kann man es ja nicht prüfen.
- und im Script ggf. alle 5 Sekunden per Javascript dasselbe: Vergleiche altes AccessSecret (vom Zeitpunkt des Ladens der Seite aktuelle, kann man ja als Javascript-Parameter generieren) mit dem neuen aus dem Session-Storage und triggere notfalls ein Zwangs-Logout. Das kennen wir ja auch von vielen Webseiten (auch Webling selbst).
Noch ein (krude?) Idee:
- man schreibt (jedesmal, wenn man ein AccessSecret vom Portal = nicht von "self" bekommt) die SessionID zusammen mit der datetime per API in einen "Secret Parameter" des aktuellen User in Webling
- bei JEDEM Script-Aufruf prüft das Script per REST API, ob es in Webling ANDERE User gibt mit derselben SessionID aber NEUERER datetime --> wenn ja: aktuelles Fenster Zwangs-Logout
- für Erkennung von "self" über http_referrer (unsicher weil manipulierbar) gehen oder über zweites AccessSecret, das sich jedes mal ändert (oder so)
- ODER noch anders: bei jedem Script-Aufruf mit einem neuen AccessSecret (= von einem anderen User als zuvor) wird das AccessSecret des ZUVOR angemeldeten User verändert. Das kann man ermitteln, indem man nach denjenigen Usern mit derselben SessionID sucht (und ggf. wieterer Parameter). Somit sind keine Zugriffe auf Daten des zuvor angemeldeten Mitglieds mehr möglich (vorausgesetzt alle get/set-Befehle checken das AccessSecret).
- war die letzte Idee vor dem Ins-Bett-Gehen, also nicht ausgegoren ... aber vielleicht interessant... oder vielleicht gefährlich
Und wie so oft eine Frage an @demian_holderegger : Gibt es die Möglichkeit, in normalen Portal-Seiten im HTML-Modus Images mit EXTERNEM INHALT (also z.B. <img src="https://<MEINEDOMAIN>/ExtTest.php?image&accesssecret={{AccessSecret}}"> einzubinden? Noch besser: für das LOGO? Das wäre eine Möglichkeit, das AccessSecret unseres eigenen Scriptes bei Neu-Login sofort zu "resetten". Das wäre dann ein "Portal-Login-Hook".