Forum: PC-Programmierung CORS mit PHP und Javascript

Der Browser checkt beim erhalt der Antwort, ob der Origin passt. Per 
default ist der erlaubte Origin der von der Url, wo der Request hin 
soll. Aber wenn der Server den "Access-Control-Allow-Origin" mit der 
Antwort mit senden, können noch weitere origins erlaubt werden. Der 
Origin, der mit dem erlaubtem gegengecheckt wird, ist der der Seite, die 
das script ausführt. Der origin ist der Teil der url aus 
schema://domain:port, ohne den Pfad dahinter. In manchen speziellen 
Situationen (z.B. wenn Authentifizierungsdaten per SSO mitgesendet 
werden sollen) macht der Browser aber vor dem echten request noch einem 
OPTION request, um zuerst zu prüfen, ob der request gemacht werden darf. 
Bei dem option request ist dann aber das gleiche spiel. Es gibt noch ein 
paar andere cors header, z.B. einer für die erlaubten Methoden. In 
manchen Situationen & für manche cors header funktioniert auch der wert 
* nicht, da muss man dann explizit sein. Das ist auch, warum gewisse 
APIs Access-Control-Allow-Origin auf den Wert des Origin headers vom 
Request setzen.

Ich würde mal mit "curl -v" oder einem Tool wie postman oder so mal 
nachsehen, ob die Header auch tatsächlich gesetzt werden.
In php kann man die header nur setzen, solange sie noch nicht gesendet 
sind. u.A. darf also noch nichts ausgegeben worden sein. Dass kann recht 
schnell mal passieren, z.B. wenn man einen abstand, newline, oder 
unicode BOM vor dem <?php stehen hat, oder sonst irgendwo im Code 
irgendwas ausgegeben wurde. Wenn die Warnungen ausgeschaltet sind, 
bekommt man davon auch gar nichts mit.

Die Browserfehlermeldung sagt ja recht eindeutig das dev.irgendwo.de 
scheinbar real keinen Access-Control-Allow-Origin HTTP-Header sendet.
Da würde ich im Netzwerk-Tab in den Dev-Tools des Browsers (F12-Taste) 
als erstes mal nachschauen wie die Header im Response und der Response 
selbst denn tatsächlich aussehen...

bluppdidupp schrieb:
> Da würde ich im Netzwerk-Tab in den Dev-Tools des Browsers (F12-Taste)
> als erstes mal nachschauen wie die Header im Response und der Response
> selbst denn tatsächlich aussehen...

Ich habe da mit cross origin geschichten schlechte erfahrungen mit den 
browser dev tools gemacht. Die zeigen da nicht immer alles 1:1, bei den 
cors geschichten.

Ich fand diese Doku dazu am hilfreichsten. Konnte es damit in mehreren 
Programmiersprachen auf Anhieb umsetzen: 
https://developer.mozilla.org/de/docs/Web/HTTP/CORS

Kolja L. schrieb:
> kann mir hier jemand auf einfache Weise erklären, wie CORS im
> Zusammenhang eines lokal ausgeführten Javascriptes und einer PHP API auf
> einem Webserver funktioniert?

Wiso?

Bei der Antwort ist am Anfang vermutlich noch ein "GET /php/api.php 
HTTP/1.1" oder so, dass man nicht sieht.
Die Antwort sieht merkwürdig aus. Diese Header (scheme:, filename: 
Übertragen:) habe ich in einer HTTP/1.1 Response noch nie gesehen. (und 
wieso scheme:https, wenn im fetch http steht?!?). Den 
"Access-Control-Allow-Origin" Header sieht man da auch nicht.
Kannst du eventuell mit Wireshark oder so nochmal nachsehen, ob da nicht 
was anderes gesendet wird?
Oder macht der Server da vielleicht sogar irgend welchen experimentellen 
HTTP/2 / SPDY oder HTTP/3 / QUIC Nonsens, der da zu Problemen führt?

Du musst auf dem Server zwei HTTP Methoden implementieren:

> OPTIONS http://localhost./php/api.php?list

Muss mit einem leeren Body und folgenden Header beantwortet werden:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: *
Access-Control-Allow-Headers: *
Access-Control-Max-Age: 86400

Diese Requests hast du in deinen Logs womöglich nicht gesehen, weil der 
Browser die Berechtigungen cached, so dass er den OPTIONS Request beim 
Wiederhol-versuch normalerweise nicht erneut sendet.

Danach ruft der Browser auf:
> GET http://localhost./php/api.php?list

Das muss mit folgendem Header beantwortet werden:

Access-Control-Allow-Origin: *

und was du sonst noch so als Response zurück geben wolltest.

Anstelle der Sternchen kannst du natürlich restriktiver sein 
(Komma-separierte Listen), aber damit würde ich erstmal anfangen.

Der Status 404 erscheint mir wichtig. Offenbar findet es die Datei unter 
"http://localhost./php/api.php?list"; nicht. Vermutlich ist dass das 
Hauptproblem.

Vermutlich hat der Server Probleme mit dem "localhost." Spezifischer, 
dem . am Schluss. "localhost." ist zwar eine gültige fqdn, es ist das 
selbe wie localhost, nur dass die search Domains beim DNS Lookup nicht 
beachtet werden. Nur senden Browser dann "Host: localhost." auch statt 
"Host: localhost", und die meisten Webserver oft nicht so clever zu 
merken, dass "Host: localhost." und localhost den selben vhost betreffen 
sollten. (Zumindest nicht ohne spezielle Zusatzkonfigurationen)

Also nimm den . da mal weg, damit da "http 
://localhost/php/api.php?list" draus wird. Oder alternativ, mach aus dem 
"http ://localhost" statdessen "http ://localhost/", dann wird daraus 
"http ://localhost/./php/api.php?list", was dann wieder passen sollte.

Alternativ kann man die URL auch mit der URL Klasse zusammensetzen:

1

const url = "http://localhost";

2

fetch((new URL("./php/api.php?list", url)).href, { method: "GET" })

https://developer.mozilla.org/en-US/docs/Web/API/URL

Kolja L. schrieb:
> Oder wie kann/soll ich die Anfrage (GET,POST,OPTIONS) auseinander
> sortieren?

Ist schon richtig so.