Via react native maak ik een app. De inloggegeven sla ik op bij de database van mijn webhosting. Hiervoor heb ik een api in php geschreven en die draait nu ook in productie bij hostnet. Als ik de app test (via google chrome) en de signup gegevens invul krijg ik deze foutmelding. De http heb ik onherkenbaar gemaakt.
Access to fetch at 'http//..........login.php' from origin 'http://localhost:*******' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.
Als lake weet ik niet zo goed wat ik nu moet doen. Na een paar dagen zoeken via google krijg ik zoveel zoekresultaten/vragen/oplossingen dat ik 'door de bomen het bos niet meer zie'. Veel CORS foutmeldingen lijken op elkaar en antwoorden zijn vaak verschillend.
Oplossingen die ik zelf gevonden heb:
- Kan/moet ik CORS policy uitschakelen? volgens mij mag dat niet ivm beveiliging
- Moet ik nog een server in de frontend maken met node.js? Is dit voor mij van toepassing?
- Moet ik een CORS plugin installeren voor google Chrome? (volgens mij los ik het probleem hiermee niet op)
- In de file index.php moet ik het onderstaande zetten met een paar aanpassingen. (ik heb alleen db.php, signup.php en login.php)
Als een gebruiker via een app direct connectie zoekt, dan moet je normaliter elke host toestaan.
Dat klopt inderdaad, maar dan zou ik moeten kiezen voor:
header("Access-Control-Allow-Origin: *");
Maar dan kan iedereen toegang krijgen tot de database, toch ook buiten de app? Dat is ook niet de bedoeling ivm veiligheid.
Welke poorten zoek je dan precies? En weet je zeker dat je wel 'localhost' wilt? Of doe je dat vanwege je proxy?
Eigenlijk wou ik geen localhost maar dat werd aanbevolen, waarom begrijp ik ook niet echt.
IEn waarom poort 21 van FTP? Die doet niks met HTTP-requests hoor.
Dat had ik hier inderdaad niet moeten zetten, dat was een laatste poging omdat ik er niet meer uitkwam.
CORS heeft niks met databases te maken. Ik neem aan dat je credentials daarvan in je API zitten, en niet in je app?
Ik heb het idee dat je maar een beetje aanrommelt, zonder te weten wat je doet. Dat lijkt mij erg gevaarlijk, los van CORS.
CORS is meer een drempel dan een echte beveiliging. Je kan er mee bepalen welke externe sites jouw scripts mogen aanroepen. Als iemand het los via bijv. wget of cURL aanroept, dan kan dat gewoon.
De credentials zitten inderdaad in mijn api en niet in mijn app.
De reden dat ik het vraag is dat ik een goed beveiligde en werkende oplossing zoek.
Los van dit onderwerp heeft het weinig te maken met "erg gevaarlijk", het overige is alleen het schrijven van een app.
Fijn dat je me toch wilt helpen. Ik denk dat ik nu begrijp welke stappen ik moet volgen om het werkend te krijgen. Curl heb ik gedownload, werkt in opdrachtprompt en volg nu de instructies hieronder.
How to avoid the CORS preflight
The code in the question triggers a CORS preflight—since it sends an Authorization header.
https://developer.mozilla.org/docs/Web/HTTP/Access_control_CORS#Preflighted_requests
Even without that, the Content-Type: application/json header will also trigger a preflight.
What “preflight” means: before the browser tries the POST in the code in the question, it first sends an OPTIONS request to the server, to determine if the server is opting-in to receiving a cross-origin POST that has Authorization and Content-Type: application/json headers.
It works pretty well with a small curl script - I get my data.
To properly test with curl, you must emulate the preflight OPTIONS the browser sends:
curl -i -X OPTIONS -H "Origin: http://127.0.0.1:3000" \
-H 'Access-Control-Request-Method: POST' \
-H 'Access-Control-Request-Headers: Content-Type, Authorization' \
"https://the.sign_in.url"
…with https://the.sign_in.url replaced by whatever your actual sign_in URL is.
The response the browser needs from that OPTIONS request must have headers like this:
Access-Control-Allow-Origin: http://127.0.0.1:3000
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type, Authorization
If the OPTIONS response doesn’t include those headers, the browser will stop right there and never attempt to send the POST request. Also, the HTTP status code for the response must be a 2xx—typically 200 or 204. If it’s any other status code, the browser will stop right there.
The server in the question responds to the OPTIONS request with a 501 status code, which apparently means it’s trying to indicate it doesn’t implement support for OPTIONS requests. Other servers typically respond with a 405 “Method not allowed” status code in this case.
So you’ll never be able to make POST requests directly to that server from your frontend JavaScript code if the server responds to that OPTIONS request with a 405 or 501 or anything other than a 200 or 204 or if doesn’t respond with those necessary response headers.
The way to avoid triggering a preflight for the case in the question would be:
if the server didn’t require an Authorization request header but instead, e.g., relied on authentication data embedded in the body of the POST request or as a query param
if the server didn’t require the POST body to have a Content-Type: application/json media type but instead accepted the POST body as application/x-www-form-urlencoded with a parameter named json (or whatever) whose value is the JSON data
In mijn login.php heb ik dit staan:
header("Access-Control-Allow-Origin: http://localhost:19006";);
header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
header("Access-Control-Allow-Headers: Content-Type, Authorization");
header("Content-Type: application/json");
Zou ik dan het onderstaande aan moeten passen?
header("Access-Control-Allow-Origin: http://localhost:19006";);
header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
header("Access-Control-Allow-Headers: Content-Type, Authorization"); header("Content-Type: application/json");
En dit
application/x-www-form-urlencoded with a parameter named json (or whatever) verwerken in mijn signin.js script?
Nee ik werk vanaf thuis met een laptop. Maar eerder vroeg ik of dit juist was:
header('Access-Control-Allow-Origin: *');
jou reactie: Als je jan-en-alleman een request wilt laten doen, dan kan je dat proberen. mijn reactie: Bedoel je hiermee dat dit ook een oplossing is voor een signin/registratie pagina van een app. Of wil je hiermee aangeven dat de beveiliging van je database dan zo lek als een mandje is. jou reactie: Ga zelf eens na of www.randomdomeinvaniemand.nl ook een aanroep mag doen naar je scripts via een AJAX-request.
etc.....
Ik ga ervan uit dat * sowieso niet goed is omdat dan iedereen toegang heeft.
Moet ik dan een Loopback-adres + 19006 gebruiken? Maar dat is toch hetzelfde als localhost?
Gaat het om een app? Die maakt requests van verschillende hostnames.
Of gaat het om een site? Die draait op één hostname.
Verder is CORS een drempel, en geen waterdichte beveiliging. Als de beveiliging in je script die extern aangeroepen wordt goed beveiligd is, dan is het toch ook prima? Zelf zou ik het in sommige gevallen ongewenst vinden als een API-request met data door een externe site uitgelezen wordt. Die afweging moet je zelf maken.
Het gaat inderdaad om een app. Zou je de voorgaande berichten ook willen lezen en aan willen geven wat ik precies moet doen. Stap voor stap. Ik ben loop hier nu al ruim 2 weken op vast en ik kom niks verder.
