drust
Jepp, das geht ganz einfach, denn das im iFrame laufende Script gehört ja dir. Du kannst darin alles machen, was eine Webseite kann: inputs, forms, javascript, POST/GET, etc. und natürlich vorher noch prüfen, ob das zum accesssecret gehörende Mitglied die Sachen auch sehen und/oder ändern können soll, nach von dir ganz allein festgelegten Regeln.
Die "Verbindung zum Mitglied" geschieht auch weiterhin über das accesssecret, das du bei jeden GET/POST request übergeben musst, am einfachsten explizit=normal (oder als Session-Cookie).
Das heißt: dein Script generiert dann Formulare, Eingabefelder, etc. und baut das accesssecret da so mit ein, dass dieses auch bei jedem folgenden submit (GET oder POST, egal) wieder gesendet wird.
Voila.
Hier ein super-simples Beispiel mit PHP-generierter html-form und accesssecret als hidden input. Ist getestet. Funktioniert.
<form>
<input name="accesssecret" type="hidden" value="<?php echo $accessSecret; ?>">
<input name="editRestricted" type="text" value="<?php echo $thisMember["properties"]["EditierbarerParameter"]; ?>" title="editierbar">
<input name="viewRestricted" type="text" value="<?php echo $thisMember["properties"]["ReadOnlyParameter"]; ?>" readonly title="readonly">
<input type="submit" value="Abschicken" />
</form>
Um die entsprechenden Parameter im "normalen" Mitgliederportal versteckt zu halten, muss natürlich im Admin-Panel die Kategorie auf "nicht sichtbar" stehen. Per API hast du dann wieder vollen bzw. den für den APIKey konfigurierten Zugriff ... und kannst machen, was du willst.
Das sieht dann z.B. so aus:
Achtung - Sicherheit!
Da das ganze in einem iFrame läuft, läuft es selbstverständlich auch OHNE iFrame und OHNE das Webling-Mitgliederportal drum herum., also mit der direkten URL: https://<MEINEDOMAIN>/ExtTest.php?accesssecret={{AccessSecret}}. Es ist eine öffentlich erreichbare Seite, die von jedermann aufgerufen werden kann. Das kannst du nicht wirklich verhindern. Also darf das Script eigentlich gar nichts tun, wenn kein (korrektes) accesssecret übertragen wird, oder gleich 404! Und deshalb ist auch die Länge des accesssecret so wichtig, mindestens 2256.
Natürlich kannst du weitere Prüfungen einbauen. Da der erste Aufruf ja aus dem Webling-Portal erfolgen soll, kannst du den "HTTP_REFERER" im $_SERVER Parameter prüfen, ob der https://<<DEINEDOMAIN>>.webling.eu lautet. Bei den nächsten Aufrufen durch das Script ist natürlich das Script selbst der referrer. Vielleicht kann man hier noch weitere Sicherheiten einbauen. Z.B. Cookies/@session_start();, die ablaufen. Wenn abgelaufen, dann MUSS der Visit vom Portal kommen, die folgenden werden dann innerhalb der Cookie-Lebenszeit auch von "sich selbst" erlaubt. Allerdings kannst du "referer spoofing" auch nicht zuverlässig verhindern. Vielleicht ist das eine Motivation für ein zweites secret, dass sich JEDESMAL verändert (pro User, dann nur ein solches Fenster zu Zeit offen, kennt man von anderen Webseiten, kann aber auch in der Benutzung nerven). Vielleicht gibt es dazu aber auch schon bewährte Design Pattern. Kannst ja mal Googeln oder ChatGPTn. Viel Spaß bei der Umsetzung. Lass uns dann daran teilhaben.
Ab hier nicht mehr so wichtig ...
Es gibt noch einen weiteren kleinen iFrame-"Effekt", nämlich, dass im Mitgliederportal ein neuer Klick auf den Menüpunkt "ExtTest" die Seite nicht (immer?) neu läd. Vielleicht liegt es am Browser-Caching, vielleicht ist da auch noch Webling-Javascript dazwischen, und das geht einfach nicht davon aus, dass das iFrame seinen Inhalt selbstständig ändert ... und "verweigert" den Reload. iFrames sind ja ganz bewusst "disconnected" vom Rest der Seite. Aus Sicherheitsgründen, daher kommt vmtl. auch dieses "nicht wissen, was drin ist". Ausweg: erst einen anderen Menüpunkt anklicken (z.B. "Mein Profil"), dann wieder zurück. Oder Browser-Page-Reload (F5), der dann anders als sonst die letzten GET/POST Daten des iFrame höchstwahrscjeinlich NICHT mitschickt. Und/oder einen "Reload-Button" direkt im iFrame ganz oben anbieten.
Und noch ein kleiner Nachtrag: Versucht bloß nicht, das secret erst als 256-Bit-Integer zu erzeugen (also rand(0,pow(2,256)-1)) und dann nach base64 zu konvertieren. Solche Datentypen gibt's nicht, oder sie sind sehr langsam. In PHP geht's so viel schneller: base64_encode(random_bytes(32));
