7. Persistenz, Autorisierung, Cookies

7.6 Web-APIs und CORS

Erinnern Sie sich an den Login-Server 13-login-server.zip und das Übersichtsdiagramm:

Jedes violett Polygon ist ein Endpoint des Login-Servers, sprich eine Methode, die aufgerufen werden kann. Viele davon entsprechen mehr oder weniger einer Html-Seite (manchmal dynamisch erzeugt): GET / lädt die Datei home.ejs (bzw. die Html-Datei, die mithilfe der render-Methode des Packetst ejs daraus erstellt wird), GET /login lädt die Datei login.ejs und so weiter. Nicht in das Schema passt GET /get-messages.

node src/server.js

Das war bis jetzt bei unseren Anwendung immer so: der Server stellt Endpoints zu Verfügung, die entweder direkt vom User oder von Html-Forms und Links geladen werden, oder eben von Ajax-Requests. Diese Html-Forms und Ajax-Requests befanden sich auch immer auf Seiten, die selbst vom gleichen Server erstellt wurden. Es gab also nur zwei Parteien: Nutzer (plus Browser) und Server. Wenn eine dritte Partei hinzukam, die "von außen" Requests schickt, wie im Kapitel 7.4, dann haben wir das meist als unlauteren Zugriff betrachtet und in der Tat verschiedene Angriffsszenarien durchgespielt. In diesem Kapitel jedoch geht um völlig legitime Anwendungsfälle, wo die Endpoints von einer dritte Partei verwendet werden.

Ein weiterer Endpoint des Login-Servers

Unser Login-Server hat allerdings noch einen weiteren Endpoint, der nicht von irgendeiner eigenen Seite verwendet wird: GET /fib-raw. Probieren Sie es: öffnen Sie http://localhost:4013/fib-raw?n=20 in einem neuen Tab. Das Ergebnis ist keine Html-Seite, sondern reiner Text: {"result":6765}. Der Server auf localhost:4013 stellt uns also nicht nur Webseiten (in Html) zur Verfügung, sondern auch die Dienstleistung, über den Url localhost:4013/fib-raw mit Suchparametern im Format n=... Fibonacci-Zahlen zu berechnen. Dieser Service kann nun von jeder Applikation benutzt werden, die Http-Requests erstellen kann. In Fachsprache: der Server localhost:4013 stellt ein API (Application Programmer Interface) zur Verfügung, mit dessen Hilfe man Fibonacci-Zahlen berechnen kann. Bringen Sie bitte die mentale Flexibilität auf, die doch in ihrer Nützlichkeit beschränkte Dienstleistung Fibonacci-Zahlen berechnen durch etwas Sinnvolleres zu ersetzen, beispielsweise Text von Polnisch auf Deutsch übersetzen.

Jetzt sind Sie dran! Erinnern Sie sich daran, wie man mit Javascript Http-Requests erstellt (Ajax, Kapitel 6.1).

Cross-Site Resouce Sharing

Wenn Sie die vorherige Übungsaufgabe erfolgreich gemeistert haben und ein Frontend, nennen wir es fib-frontend.html, ersetllt haben, dann sehen Sie, dass der Ajax-Request Ihrer Seite gescheitert ist und folgende Fehlermeldung erzeugt hat:

Access to XMLHttpRequest at 'http://localhost:4013/fib-raw?n=8' from origin 'null' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Deutlicher wird es noch, wenn Sie Ihr Frontend fib-frontend.html nicht direkt vom File-Explorer öffnen sondern es separat von einem Http-Server aus hosten:

cd fibonacci-frontend
http-server .

und dan auf 127.0.0.1:8080/fib-frontend.html klicken. Dann schaut die Fehlermeldung so aus:

Access to XMLHttpRequest at 'http://localhost:4013/fib-raw?n=8' from origin 'http://127.0.0.1:8080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Was passiert? Das Problem ist, dass localhost:4013 und 127.0.0.1:8080 zwei verschiedene Server sind. Die Seite fib-fontend.html wurde über letzteren geladen, der Service /fib-raw aber bei ersterem angefragt. Nun ist es bei Ajax-Requests üblicherweise so, dass der Request an den gleichen Server geschickt wird, von dem die Seite geladen wurde. Wenn nun diese Server nicht identisch sind, dann ist "etwas im Gange", und die Grundeinstellung ist, den Request zu blockieren. Das erinnert uns an die Same-Site-Policy, die geregelt hat, wann Cookies mitgeschickt werden sollen, wenn ein Request an einen anderen Server geht.

Um zu verstehen, wie und warum CORS-Requests blockiert werden und wie man diese Blockierung aufhebt, müssen wir verstehen, welche Parteien hier involviert sind:

1. Der API-Anbieter, hier also localhost:4013.
2. Der Frontend-Server, hier also 127.0.0.1:8080.
3. Der Nutzer, also Sie.
4. Der Browser, in meinem Falle Google Chrome.

Wenn Sie die letzte Übungsaufgabe gelöst haben, dann sehen Sie, dass der API-Server durchaus den Request beantwotet hat und die Fibonacci-Zahl \(F_n\) schickt. Es ist also der Browser, der den Response zwar erhält, sich aber weigert, die Daten dem Javascript-Code zur Verfügung zu stellen! Es ist also der Browser, der den Request blockiert und jemanden schützen will. Oder besser gesagt: der Browser blockert nicht den Request, sondern den Response!

CORS-Requests erlauben

Ein API kann ja nur dann seine Dienste anbieten, wenn es CORS-Requests erlaubt. Aber wir haben ja gesehen: der API-Server beantwortet die CORS-Requests ja in jedem Fall. Es ist der Browser, der sich eventuell weigert, das Ergebnis weiterzuverwenden. Hierfür muss nun also der API-Server dem Browser signalisieren, dass er damit einverstanden ist, dass der Response des CORS-Requests verwendet wird. Hierfür wird im Response der Header Access-Control-Allow-Origin gesetzt, gefolgt von einer Liste von Dritt-Servern, für die CORS-Requests erlaubt sein sollen. In Node.js sieht das so aus (Zeilen 61-65 im Quelltext von 13-login-server/src/server.js):

  const cors_options = {
    origin: ['http://localhost:8080', 'http://127.0.0.1:8080'],
    credentials: cors_credentials
  }
  app.use(cors(cors_options));

node src/server.js --cors

  origin: '*', // origin: ['http://localhost:8080', 'http://127.0.0.1:8080'],