Delphi-PRAXiS - Frage zur Architektur/Technik einer Webanwendung

Zitat:

Zitat von Darlo (Beitrag 1358616)

Mir fehlen leider auch die richtigen Suchbegriffe um mich tiefer in das Thema einlesen zu können.

Bis jetzt habe ich einen DataSnap-Rest-Server aufgesetzt. Mit dem kann ich #1 abbilden. Wie komme ich aber mit #2 weiter? Könnte folgender Weg funktionieren:
Andere Webseitenbetreiber die meine Funktionen integrieren wollen bekommen von mir ein php-Script das einen Webservice aufruft das den html code zurückliefert und quasi per echo die Seite ausgibt. Javascript ist ja leider keine Lösung, da ich dann nur weiß welcher Endbenutzer die Funktionen benutzt und nicht über welchen Server er kommt.

Würde mich über Input bzw. die richtigen Schlagworte zur Recherche freuen.

Willkommen im Browser :P:twisted::thumb: Oder anders ausgedrückt: Wie "alt" kann der Zielbrowser sein?
Wenn du Steinzeitbrowser ausschließen kannst, dann kannst du das sehr wohl mit Javascript machen. Stichwort CORS (= Cross Origin Resource Sharing). Im Prinzip funktioniert das sehr einfach (!), da moderne Browser da schon alleine ziemlich entgegenkommend sind.

Ablauf so einer Kommunikation:

fremdeSeite.tld bindet ein javascript ein, das von dir kommt. Dieses File macht asynchron eine Anfrage an deine Seite.
Diese Anfrage wird nicht einfach so vom Browser erlaubt (also deineSeite.tld <> fremdeSeite.tld). Browser schicken da automatisch vor der ersten Anfrage eine so genannte Preflight Message an deineSeite.tld. Das ist eine http OPTIONS Anfrage an deinen Server, indem ein Headerfeld "Origin" auf "https://fremdeSeite.tld" gesetzt ist.
deineSeite.tld antwortet dann mit "Access-Control-Allow-Origin" gesetzt auf "https://fremdeSeite.tld" oder "*" für alle Seiten. Man kann auch auf verschiedene HTTP Methoden beschränken.
Danach weiß der Browser, dass er anfragen darf und schickt die eigentliche asynchrone Request an deinen Server. In diesen Anfragen ist die "Origin" im Headerfeld auch immer auf die Seite gesetzt und man sollte wie oben beschrieben antworten.

mehr Infos zu CORS:

klick!

Auf diese Weise musst du nur die API (z.B. als REST Interface) von deiner Seite zur Verfügung stellen und der Fremdbetreiber kann sehr frei gestalten, wie er diese API nutzen möchte.

Willst du auch alte Browser unterstützen, oder wirklich den Fremdserver dazwischenhängen, wird das sicherlich auch gehen. Also um konkret deine Frage zu beantworten: Ja, man kann einfach auch php zur Verfügung stellen.

Das Schöne: Das interessiert dich von der Gestaltung der REST API nicht. Javascript wird die Origin setzen, andere Sprachen (wie auch php) können, diese Header setzen, werden das aber im Allgemeinen nicht automatisch tun. Du wirst niemanden daran hindern können, die für Javascript gedachten Anfragen nicht auch einfach über einen Drittserver anzufragen (ja, es sei denn man schaut eventuell noch die remote IPs reverse an, aber ich glaube das verlässt den Themenbereich deiner Frage).

Weil du CSS angesprochen hattest/an noch anderen Lösungen interessiert bist: Ich kenne die genauen Dinge nicht, die du damit abwickeln willst. Was auch geht: Biete einen Link an, der stark parametrisiert werden kann (z.B.
Code:

https://deineSeite.tld/auth?organisation=fremdeSeite.tld&user=pink_panther&param=....&...blah

). Diese Seite soll als Popup oder als iframe von fremdeSeite.tld aufgerufen werden. Du erlaubst, dass man bei dir die Gestaltung anpasst (z.B. welche drei Farben sollen als Seitenhauptfarben verwendet werden, welches Bild soll geladen werden, um das Popup individuell zu branden, etc). Diese Gestaltung integrierst du in dein CSS (das dann halt dynamisch bei dir beim Aufruf der Seite ausgeliefert werden wird; je nach Link-Parametrisierung).

Damit jeder nur seine Daten sieht und du ja hierfür ein Login spendieren möchtest: Http REST ist ja stateless (in der reinen, schönen akademischen Welt :P) und das heißt, dass es eigentlich kein Zustand auf dem Server zwischen den Anfragen gehalten werden soll (ja, das ganze wird grade ein wenig aufgeweicht usw).
Aber in der Praxis macht man das normalerweise über tokens. Also login über dein REST interface, wie oben im Javascript Teil beschrieben returned dein token (= irgend ein identifizierender langer geheimer String) der für die Dauer der Sitzung gültig ist (das heißt auch, dass das token am besten irgendwann automatisch auf dem REST Server als ungültig markiert werden muss).
In jeder weiteren Anfrage schickst du dein token mit. Wenn du das zum Beispiel in Cookies ablegst, dann macht die Browser das auch wieder schön automatisch :) Nur wenn das token gesetzt und gültig ist, gibst du Daten entsprechend der damit assoziierten Berechtigung an den Nutzer heraus.

Server2Server auth brauchst du bei der Javascript Lösung eigentlich nur beim Login. Denk halt daran, dass du bei egal was für einer Lösung darauf achtest, dass Nutzercredentials beim Login immer auf deiner Seite eingegeben werden und nicht auf der Fremdseite. Sonst kann die böse fremdSeite.tld "man-in-the-middle" spielen und die Passwörter deiner Nutzer abgreifen. Ich nehme an, dass die Seite immer nur auf einen Teil der Nutzerdaten eines Nutzers zugreifen können soll...
Wenn du dazu Genaueres wissen möchtest, kann ichs gerne weiter ausführen, wie die Anfragereihenfolge mit den drei Parteien Fremdserver, Server, Browser sicher möglichst sicher ablaufen könnte.

Ich hoffe, ich konnte ein wenig Hintergrund schaffen! :P

Brighty