Waarom blijft mijn CORS policy requests blokkeren?

[RoelZ]

Hi,

Al een geruime tijd loop ik tegen een CORS issue aan, die ik telkens (wanneer ik mijn moed weer terug heb gevonden) probeer op te lossen, maar ik loop echt gigantisch tegen de muur omdat het inmiddels onlogisch is geworden voor me.
Ik hoop met deze vraag dat iemand me op een andere gedachte kan krijgen waardoor ik wellicht meer inzicht krijg in het probleem.

Here goes...
(ik gebruik even aliassen voor mijn domeinen. Ik wil deze best in een DM delen btw)

Ik heb een backend draaien (Wordpress) op wordpress-domein.nl
Ik heb een frontend draaien (Vue.js) op sub.wordpress-domein.nl

Ik heb een development (backend) draaien op wordpress.dev-domein.nl
Ik heb een development (frontend) draaien op localhost:8080

Mijn Vue.js project maakt gebruik van Axios om te connecten met Woocommerce (REST API).

JavaScript: woocommerce.js

import Vue from 'vue'
import axios from 'axios'

const WC_API = axios.create({
  baseURL: process.env.NODE_ENV === 'production' ? process.env.VUE_APP_WC_URL : process.env.VUE_APP_WC_DEV_URL,
  auth: {
    username: process.env.VUE_APP_WC_USER,
    password: process.env.VUE_APP_WC_PASS
  },
  headers: {
    'Content-Type': 'application/json',
  }
})

export default Vue.prototype.$woocommerce = WC_API;

Voor mijn lokale omgeving heb ik een proxy ingesteld.

JavaScript: vue.config.js

module.exports = {
  devServer: {
    proxy: {
      '/wp-json/': {
        target: 'https://www.wordpress-domein.nl/',
        changeOrigin: true
      },
      '/pie/psdService/': {
        target: 'https://image.adobe.io/',
        changeOrigin: true
      },
      '/api/v2/': {
        target: 'https://panel.sendcloud.sc/',
        changeOrigin: true
      }
    }
  },
  publicPath: process.env.NODE_ENV === 'production'
    ? '/apps/dashboard/'
    : '/',
}

'/apps/dashboard/' is hier tijdelijk ingezet om zo vanuit het hoofd domein de app toch aan de praat te krijgen.

Nu wil ik graag voor productie kunnen deployen naar Firebase.
Deze staat ingesteld en kan ik aan via sub.wordpress-domein.nl, maar krijg dan de foutmelding.

Access to XMLHttpRequest at 'https://www.wordpress-domein.nl/wp-json/wc/v3/orders/?status=processing' from origin 'https://sub.wordpress-domein.nl' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Plaats ik mijn /dist map handmatig op mijn server (wordpress-domein.nl) in de map /apps/dashboard/ geeft het geen problemen.
Mijn inziens logisch omdat de aanvraag dan ook vanuit het trusted domein komt.

Ik heb geprobeerd om Headers toe te voegen. In dit geval via

PHP: functions.php

header("Access-Control-Allow-Origin: https://sub.wordpress-domein.nl");
header("Access-Control-Allow-Headers: *");
header("Access-Control-Allow-Methods: GET, OPTIONS");
header('Access-Control-Allow-Credentials: true');
header('Access-Control-Max-Age: 86400');

Voorheen nog netjes een check voor whitelisting eromheen gebouwd, maar gezien mijn hopeloosheid staat het nu even direct geset


Zegt bovenstaande jullie iets van wat ik verkeerd doe?


Wat mij nog vreemd blijft zijn de volgende dingen:

1. via Postman kan ik alle data opvragen en kloppen de headers ook
2. andere plugins die gebruik maken van dezelfde API (zoals Sendcloud) kunnen ook alle data opvragen, no matter what
3. Roep ik de API van mijn dev omgeving aan vanuit sub.wordpress-domein.nl, krijg ik geen error

Mijn vermoede is nu dat het iets met het SSL certificaat te maken heeft, maar hier raak ik volledig zoek.

p.s: erg bedankt voor je tijd!


Oplossing
In de meest voorkomende gevallen is een CORS vaak op te lossen door een wijziging van de Request of Response Headers. Zie hiervoor de reactie reacties.

Voor mijn probleem lag de oorzaak echter net iets dieper en had het ook te maken met het blokkeren van de Preflight requests vanuit mijn server.

Voor de volledigheid heb ik een samenvatting gemaakt, hopende hiermee iemand met dezelfde struggle hiermee gigantisch tijd te besparen.

[ Voor 6% gewijzigd door RoelZ op 12-09-2020 09:02 . Reden: Oops, toch een echte verwijzing ]

[Anoniem: 882605]

Als je me even de gegevens deelt via dm kijk ik even (heb zelf ook een website in Vue draaien, heb ook CORS problemen gehad en opgelost paar maandjes terug)

[n9iels]

Controleer in je browsers eens of deze headers wel echt aankomen. Als een proxy voor staat komen headers vaak niet juist door. Worden alle requests geblokkeerd of enkel POST? In dat geval is het raadzaam even te controleren of bij een OPTION request de headers ook worden meegestuurd. Veel frameworks doen zo een OPTION request namelijk voor een POST.

De reden waarom dit in postman wel lukt is omdat postman en andere back-end API's niks doen met CORS headers. CORS (of eigenlijk het same-origin principe) is namelijk een beveiliging die in browsers wordt afgedwongen. Het voorkomt dat een malafide website op de achtergrond een request kan uitvoeren naar jou REST API. Een browser stuurt bij een request namelijk ook de cookies mee die bij dat domein naam horen.

Stel dat een gebruiker inlogd op de website bank.nl en deze login wordt onthouden met een sessie cookie. In een wereld zonder CORS headers zou een andere website op de achtergrond requests kunnen doen naar bank.nl als de ingelogde gebruiker.

edit: Juist.... lezen n9iels. Ik ging er initieel uit dat het domein in je Access-Control-Allow-Origin header fout was. Dus lijkt echter correct. Negeer mijn uitleg dus

[ Voor 107% gewijzigd door n9iels op 01-09-2020 19:19 . Reden: Voorbeeld toegevoegd ]

[RoelZ]

Hi @n9iels , bedankt voor je volledige antwoord. Ook al zag je later dat ik inderdaad al bepaalde dingen heb geprobeerd (het is ook zo'n lang verhaal).

Ik gebruik overigens alleen een proxy wanneer ik in development zit en dus mijn requesten naar '/wp-json/' dan vanuit een ander domein wil laten komen.

In productie geeft de request in de devtools geen headers van de request of response weer..


Ik hoop dat je wellicht nog iets kunt met het volgende.

Waarom kan ik met dezelfde codebase en deploy wel de REST API aan van wordpress.dev-domein.nl maar niet die van wordpress.domein.nl ?
(dus zeg maar wel dev, maar niet productie).

Beide omgevingen draaien dezelfde Wordpress maar op een andere server met een ander SSL certificaat.

Ik heb echt het idee dat hier de oplossing moet liggen.

Ik ben inmiddels erg radeloos.


P.s. ik had met @Anoniem: 882605 nog bekeken of de Headers in .htaccess zouden werken, maar zelfs daar Allow op '*' te zetten wierp geen vruchten...

[n9iels]

RoelZ schreef op dinsdag 1 september 2020 @ 21:03:
Waarom kan ik met dezelfde codebase en deploy wel de REST API aan van wordpress.dev-domein.nl maar niet die van wordpress.domein.nl ?

Mist beide domeinnamen dus juiste Access-Control-Allow-Origin header teruggeven, met daarin dus de URL van jou Vue.js app, zou dit geen probleem moeten zijn. Het gaat bij CORS echt puur om de domeinnaam en niet om de SSL certificaten.

Als je de productie versie van die Wordpress API direct benaderd via de browser of Postman, zie je in de response dan wel de juiste headers terug? De error die je hebt geplaats in je begin post heeft het wel over een "preflight" request. Dat zou betekenen dat wanneer je een OPTIONS request stuurt de Wordpress API geen CORS headers terug geeft. Zie deze MDN documentatie over dit soort requests: https://developer.mozilla...CORS#Preflighted_requests.

Aanvullend vond ik nog dit, misschien heb je er nog wat aan: https://dev.to/robmarshal...rest-api-cors-issues-13p7

[ Voor 11% gewijzigd door n9iels op 01-09-2020 21:29 ]

[RoelZ]

Mist beide domeinnamen dus juiste Access-Control-Allow-Origin header teruggeven, met daarin dus de URL van jou Vue.js app, zou dit geen probleem moeten zijn. Het gaat bij CORS echt puur om de domeinnaam en niet om de SSL certificaten.

Zo ver ik van de docs begrijp niet helemaal correct. Inmiddels ik heb de volgende headers weer (tijdelijk) actief.
frontend

code:

'Access-Control-Request-Headers': 'Content-Type',
'Access-Control-Request-Method': 'GET',
'Content-Type': 'application/json',

backend

code:

header('Access-Control-Allow-Origin: http://localhost:8080');
header( 'Access-Control-Allow-Methods: OPTIONS, GET' );
header( 'Access-Control-Allow-Headers: Content-Type' );
header( 'Access-Control-Allow-Credentials: true' );

Wat ik begrijp van MDN CORS Preflighted requests, vraag je vanuit je request domein (localhost) altijd Requests aan, en Allow je dus niets. Vanuit de server (wordpress) biedt je wel/geen toegang.

Bovenstaande zou dus juist moeten zijn, maar ik blijf tegen dezelfde foutmelding aanlopen. Of ik het nou vanuit localhost doe of productie.

code:

Access to XMLHttpRequest at 'https://www.wordpress-domein.nl/wp-json/wc/v3//orders/?status=processing' from origin 'http://localhost:8080' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Ik heb zelfs zojuist nog heel Axios links laten liggen en de @woocommerce/woocommerce-rest-api officiele repo gebruikt. Maar ook daar loop ik weer tegen hetzelfde probleem!


Ik snap werkelijk niet dat ik de wereld mijn probleem niet uitgelegd krijg. Dan moet het toch wel bij mij liggen... zo frustrerend.
Mocht iemand nog een goede plek weten waar ik een opdracht voor deze vraag in kan schieten, let me know (hoop dat dit niet tegen de regels is!)

p.s: @n9iels , jouw laatste linkje was er een die ik ook al eerder was tegen gekomen. Ik heb het toch opnieuw een keer doorgenomen en geprobeerd, maar exact hetzelfde probleem!
Wat ik me daar nog wel af vraag.. wat is "HEADLESS_FRONTEND_URL" ... dat kan haast geen copy/paste zijn.. daar lijkt me in mijn geval sub.wordpress-domein.nl te moeten komen. Maar zo ook bij de $origin check. Dit adres moet toch exact hetzelfde zijn? Hoe zie jij dit?

[ Voor 15% gewijzigd door RoelZ op 02-09-2020 07:12 ]

[RobIII]

Anoniem: 882605 schreef op dinsdag 1 september 2020 @ 11:46:
Als je me even de gegevens deelt via dm kijk ik even (heb zelf ook een website in Vue draaien, heb ook CORS problemen gehad en opgelost paar maandjes terug)

De pest is dat niemand anders er iets van leert als dit allemaal "achter de schermen" gaat. Waarom post je niet gewoon wat je oplossing was (met voorbeeld/gefingeerde domeinen)?

[Postman]

Welkom in de wereld van CORS problemen. Je kunt hier letterlijk elke dag wel minstens 10 vragen over zien op Stackoverflow en geen enkele wordt nog beantwoord of opgelost.
De reden hiervoor lijkt wel dat er zoveel factoren zijn die bij iedereen anders zijn dat het bijna onmogelijk is dit vanaf een afstand zonder alle code op te lossen.

Nu zeg ik niet dat je jouw code perse moet delen, maar er bestaat een mogelijkheid dat je dit probleem gewoon niet gaat oplossen.

Ik kan trouwens niet goed opmaken of je al geprobeerd hebt om het niet vanaf localhost te testen, maar vanaf een echt domein. Soms denk ik dat elke browser nu alles met localhost erin standaard naar de verdoemenis schopt.

[RoelZ]

RobIII schreef op dinsdag 1 september 2020 @ 23:50:
[...]

De pest is dat niemand anders er iets van leert als dit allemaal "achter de schermen" gaat. Waarom post je niet gewoon wat je oplossing was (met voorbeeld/gefingeerde domeinen)?

Je hebt helemaal gelijk en ik moet hier me voor verontschuldigen, gezien ik geïnitieerd had om via DM de links te delen. We hadden het daaraan hier moeten bespreken.

Feit blijft wel dat we niks hebben opgelost (het is ook een redelijk korte DM).
@Anoniem: 882605 gaf aan dat hij zag dat de cors header die mijn api terugstuurt op wordpress-domein.nl staat, maar het verzoek van sub.wordpress-domein.nl komt.

Vanuit deze bevinding zijn we (voor mij opnieuw) de Headers van WP gaan aanpassen. Zowel in de functions.php als in de .htaccess. Iets wat ik in mijn voorgaande berichten gedeeld heb.

Helaas dus nog tevergeefs.
We zullen de communicatie in ieder geval hier vervolgen.

[RoelZ]

@Postman , ergens toch fijn om te weten dat je dit ook zo ervaart. Ik voel me namelijk redelijk dom inmiddels 😅
Wat ik alleen niet begrijp is dat dit op een professioneel niveau geen probleem vormt. Dan moeten hier toch wel duidelijke best practices voor zijn? Hoe kan het bijvoorbeeld dat Sendcloud (plugin voor shipment) wel toegang krijgt, ondanks wat ik doe met de Headers? Maken die gebruik van een soort middleware waarmee het nooit direct wordt opgevraagd zoals ik nu doe?

Dit vindt ik nog altijd het gemis van (goede) online tutorials. Er wordt nooit gewerkt aan een professioneel opgezette app.


Dat gezegd hebbende, even antwoorden op jouw vragen.
Ik ben bereid om mijn code te delen, echter in welke vorm zouden jullie hier dan het meeste aan hebben? Volledige codebase (en database)van beide applicaties?
Dat zou ik een erg mooie commitment vinden! 😉

Voor de andere vraag, ja ik heb het ook op andere omgevingen geprobeerd. In mijn OP had ik het volgende geprobeerd duidelijk te maken, maar misschien niet volledig.

Voor de front-end applicatie
Ik test mijn code lokaal (localhost) en wanneer ik build voor productie deploy ik naar sub.wordpress-domein.nl.
Ook heb ik dezelfde build geprobeerd handmatig in een map (/apps/dashboard/) op de server te zetten waar de backend ook draait. Dit is de enige manier die tot nu toe werkt. Maar ik dus niet wil

Voor de backend is het allemaal (nog niet zo netjes)
De codebase van productie is er niet. Dit is puur een installatron installatie geweest zonder versie beheer.
Omdat ik ook development wil vereenvoudigen heb ik een WP CLI installatie gedaan (van dezelfde WP versie) en daar alle draaiende plugins en de database van productie naar over gezet.
Dit staat dus op wordpress.dev-domein.nl.

Ook (zoals eerder vermeld) gaat het goed als ik ipv productie (wordpress-domein.nl), de development (wordpress.dev-domein.nl) REST API aanroep voor het ophalen van gegevens.

[RedFox]

Volgens mij is is dit de kern van het hele probleem:

RoelZ schreef op dinsdag 1 september 2020 @ 21:03:
In productie geeft de request in de devtools geen headers van de request of response weer..

Zolang de headers missen zal je browser de reqeuests blijven blokkeren.
Aangezien het op je development backend wel werkt is het een kwestie van vergelijken van die twee omgevingen. Zie je daar de juiste headers wel in je browser?

[Woy]

@RoelZ , je zult waarschijnlijk juist vooral aan de backend kant moeten kijken. Je front-end doet een CORS request naar de backend, maar de browser zal het response niet verwerken als de backend niet de juiste CORS headers mee terug stuurt.

In de basis is het erg eenvoudig, als je een non-simple request ( Dus bijvoorbeeld een POST ) wil doen, zal de browser een pre-flight request doen die een correcte CORS header in de response verwacht.

Zie https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Er staat ook een voorbeeldje waarmee je eenvoudig kunt testen

JavaScript:

const xhr = new XMLHttpRequest();
xhr.open('POST', 'https://bar.other/resources/post-here/');
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'application/xml');
xhr.onreadystatechange = handler;
xhr.send('<person><name>Arun</name></person>');

Ik zou eerst dus eens simpel beginnen, en kijken of je met een test script van jouw frontend origin een post request naar een test endpoint kunt doen op je backend. ( De extra header kun je natuurlijk achterwege laten als dat niet iets is wat jij gebruikt ).

Dit alles is redelijk eenvoudig in de browser te debuggen.

[RoelZ]

RedFox schreef op woensdag 2 september 2020 @ 08:14:
Volgens mij is is dit de kern van het hele probleem:

[...]

Zolang de headers missen zal je browser de reqeuests blijven blokkeren.
Aangezien het op je development backend wel werkt is het een kwestie van vergelijken van die twee omgevingen. Zie je daar de juiste headers wel in je browser?

Let hope! Zie hieronder

localhost

code:

Request URL: http://localhost:8080/wp-json/wc/v3/orders/?status=processing
Request Method: GET
Status Code: 200 OK
Remote Address: 127.0.0.1:8080
Referrer Policy: no-referrer-when-downgrade

# RESPONSE HEADERS
HTTP/1.1 200 OK
X-Powered-By: Express
date: Wed, 02 Sep 2020 06:42:07 GMT
server: Apache/2
pragma: no-cache
x-robots-tag: noindex
link: <https://www.wordpress-domein.nl/wp-json/>; rel="https://api.w.org/"
x-content-type-options: nosniff
access-control-expose-headers: X-WP-Total, X-WP-TotalPages
access-control-allow-headers: Authorization, Content-Type
expires: Wed, 11 Jan 1984 05:00:00 GMT
cache-control: no-transform, no-cache, no-store, must-revalidate
x-wp-total: 3
x-wp-totalpages: 1
allow: GET, POST
upgrade: h2,h2c
connection: Upgrade, close
vary: Accept-Encoding,User-Agent
content-encoding: gzip
content-length: 3843
content-type: application/json; charset=UTF-8

# REQUEST HEADERS
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,nl;q=0.8
Authorization: Basic Y2tfZTc2MTlmMTZkZTdlMzA3MGY4NDZjOWIxMjFhNmU3YmUzOGE5ODdiMDpjc185YzdlNjEyZDblabla
Cache-Control: no-cache
Connection: keep-alive
Cookie: PHPSESSID=166627685ba4fb6cde6a5dd1f887735c
Host: localhost:8080
Pragma: no-cache
Referer: http://localhost:8080/orders
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 Edg/85.0.564.44
status: processing

sub.wordpress-domein.nl

code:

Request URL: https://www.wordpress-domein.nl/wp-json/wc/v3//orders/?status=processing
Referrer Policy: no-referrer-when-downgrade

# REQUEST HEADERS
Provisional headers are shown
Accept: application/json
Authorization: Basic Y3NfOWM3ZTYxMmQ0OTNjMDIxMjYwOTNmNjYwNGYxNGFiNzg5YjE5N2VlMTpja19lNblabla
Referer: https://sub.wordpress-domein.nl/login?redirect=%2F
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36
status: processing

wordpress-domein.nl/apps/dashboard/

code:

Request URL: https://www.wordpress-domein.nl/wp-json/wc/v3/orders/?status=processing
Request Method: GET
Status Code: 200
Remote Address: 83.172.180.91:443
Referrer Policy: no-referrer-when-downgrade

# RESPONSE HEADERS
access-control-allow-headers: Authorization, Content-Type
access-control-expose-headers: X-WP-Total, X-WP-TotalPages
allow: GET, POST
cache-control: no-transform, no-cache, no-store, must-revalidate
content-encoding: gzip
content-length: 22
content-type: application/json; charset=UTF-8
date: Wed, 02 Sep 2020 07:05:10 GMT
expires: Wed, 11 Jan 1984 05:00:00 GMT
link: <https://www.wordpress-domein.nl/wp-json/>; rel="https://api.w.org/"
pragma: no-cache
server: Apache/2
status: 200
vary: Accept-Encoding,User-Agent
x-content-type-options: nosniff
x-robots-tag: noindex
x-wp-total: 0
x-wp-totalpages: 0

# REQUEST HEADERS
:authority: www.wordpress-domein.nl
:method: GET
:path: /wp-json/wc/v3/orders/?status=processing
:scheme: https
accept: application/json, text/plain, */*
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9,nl-NL;q=0.8,nl;q=0.7,it;q=0.6
authorization: Basic Y2tfZTc2MTlmMTZkZTdlMzA3MGY4NDZjOWIxMjFhNmU3YmUzOGE5ODdiMDpjc185Yzdblabla
cache-control: no-cache
cookie: pll_language=en; wp-settings-1=editor%3Dhtml%26libraryContent%3Dbrowse%26imgsize%3Dfull; wp-settings-time-1=1598522026; wp_woocommerce_session_1c92b923ec4c44df967b219240fd511; PHPSESSID=aa2cf0d4755f4841b59108f74a47c9e6; wordpress_test_cookie=WP%20Cookie%20check; 
pragma: no-cache
referer: https://www.wordpress-domein.nl/apps/dashboard/
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-origin
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36
status: processing

Op het domein waar ik het werkend wil krijgen (sub.wordpress-domein.nl) komen dus geen response headers naar voren...

[Merethil]

RoelZ schreef op woensdag 2 september 2020 @ 09:16:
[...]


Let hope! Zie hieronder

localhost

code:

Request URL: http://localhost:8080/wp-json/wc/v3/orders/?status=processing
Request Method: GET
Status Code: 200 OK
Remote Address: 127.0.0.1:8080
Referrer Policy: no-referrer-when-downgrade

# RESPONSE HEADERS
HTTP/1.1 200 OK
X-Powered-By: Express
date: Wed, 02 Sep 2020 06:42:07 GMT
server: Apache/2
pragma: no-cache
x-robots-tag: noindex
link: <https://www.wordpress-domein.nl/wp-json/>; rel="https://api.w.org/"
x-content-type-options: nosniff
access-control-expose-headers: X-WP-Total, X-WP-TotalPages
access-control-allow-headers: Authorization, Content-Type
expires: Wed, 11 Jan 1984 05:00:00 GMT
cache-control: no-transform, no-cache, no-store, must-revalidate
x-wp-total: 3
x-wp-totalpages: 1
allow: GET, POST
upgrade: h2,h2c
connection: Upgrade, close
vary: Accept-Encoding,User-Agent
content-encoding: gzip
content-length: 3843
content-type: application/json; charset=UTF-8

# REQUEST HEADERS
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,nl;q=0.8
Authorization: Basic Y2tfZTc2MTlmMTZkZTdlMzA3MGY4NDZjOWIxMjFhNmU3YmUzOGE5ODdiMDpjc185YzdlNjEyZDblabla
Cache-Control: no-cache
Connection: keep-alive
Cookie: PHPSESSID=166627685ba4fb6cde6a5dd1f887735c
Host: localhost:8080
Pragma: no-cache
Referer: http://localhost:8080/orders
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 Edg/85.0.564.44
status: processing

sub.wordpress-domein.nl

code:

Request URL: https://www.wordpress-domein.nl/wp-json/wc/v3//orders/?status=processing
Referrer Policy: no-referrer-when-downgrade

# REQUEST HEADERS
Provisional headers are shown
Accept: application/json
Authorization: Basic Y3NfOWM3ZTYxMmQ0OTNjMDIxMjYwOTNmNjYwNGYxNGFiNzg5YjE5N2VlMTpja19lNblabla
Referer: https://sub.wordpress-domein.nl/login?redirect=%2F
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36
status: processing

wordpress-domein.nl/apps/dashboard/

code:

Request URL: https://www.wordpress-domein.nl/wp-json/wc/v3/orders/?status=processing
Request Method: GET
Status Code: 200
Remote Address: 83.172.180.91:443
Referrer Policy: no-referrer-when-downgrade

# RESPONSE HEADERS
access-control-allow-headers: Authorization, Content-Type
access-control-expose-headers: X-WP-Total, X-WP-TotalPages
allow: GET, POST
cache-control: no-transform, no-cache, no-store, must-revalidate
content-encoding: gzip
content-length: 22
content-type: application/json; charset=UTF-8
date: Wed, 02 Sep 2020 07:05:10 GMT
expires: Wed, 11 Jan 1984 05:00:00 GMT
link: <https://www.wordpress-domein.nl/wp-json/>; rel="https://api.w.org/"
pragma: no-cache
server: Apache/2
status: 200
vary: Accept-Encoding,User-Agent
x-content-type-options: nosniff
x-robots-tag: noindex
x-wp-total: 0
x-wp-totalpages: 0

# REQUEST HEADERS
:authority: www.wordpress-domein.nl
:method: GET
:path: /wp-json/wc/v3/orders/?status=processing
:scheme: https
accept: application/json, text/plain, */*
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9,nl-NL;q=0.8,nl;q=0.7,it;q=0.6
authorization: Basic Y2tfZTc2MTlmMTZkZTdlMzA3MGY4NDZjOWIxMjFhNmU3YmUzOGE5ODdiMDpjc185Yzdblabla
cache-control: no-cache
cookie: pll_language=en; wp-settings-1=editor%3Dhtml%26libraryContent%3Dbrowse%26imgsize%3Dfull; wp-settings-time-1=1598522026; wp_woocommerce_session_1c92b923ec4c44df967b219240fd511; PHPSESSID=aa2cf0d4755f4841b59108f74a47c9e6; wordpress_test_cookie=WP%20Cookie%20check; 
pragma: no-cache
referer: https://www.wordpress-domein.nl/apps/dashboard/
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-origin
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36
status: processing

Op het domein waar ik het werkend wil krijgen (sub.wordpress-domein.nl) komen dus geen response headers naar voren...

Kan het zijn dat je URL niet resolved omdat er twee forward slashes staan in die URL (zie v3 // orders)?

code:

https://www.wordpress-domein.nl/wp-json/wc/v3//orders/?status=processing

Bij de andere twee heb je dat niet. Het is maar een idee, was het enige wat ik zo snel zag; helemaal geen response headers terugkrijgen vind ik ook vreemd.

[RoelZ]

@Woy , bedankt voor me opnieuw te herinneren hoe eenvoudig het eigenlijk is
Maar goed dat je het doet, want jouw idee om even een basic example te proberen biedt me een nieuwe richting!

Ik heb het zojuist geprobeerd. Een simpele GET request naar mijn backend

JavaScript:

const xhr = new XMLHttpRequest();
const url = 'https://bar.other/resources/public-data/';
   
xhr.open('GET', url);
xhr.onreadystatechange = someHandler;
xhr.send(); 

localhost

code:

Request URL: https://www.wordpress-domein.nl/wp-json/wc/v3/orders/9299/?consumer_key=ck_e7619f16de7e3070f846cblabla&consumer_secret=cs_9c7e612d493c02126093f66blabla
Request Method: GET
Status Code: 200 
Remote Address: 83.172.180.91:443
Referrer Policy: no-referrer-when-downgrade

# RESPONSE HEADERS
access-control-allow-credentials: true
access-control-allow-headers: Authorization, Content-Type
access-control-allow-methods: OPTIONS, GET, POST, PUT, PATCH, DELETE
access-control-allow-origin: http://localhost:8080
access-control-expose-headers: X-WP-Total, X-WP-TotalPages
allow: GET, POST, PUT, PATCH, DELETE
cache-control: no-transform, no-cache, no-store, must-revalidate
content-encoding: gzip
content-length: 1901
content-type: application/json; charset=UTF-8
date: Wed, 02 Sep 2020 07:25:53 GMT
expires: Wed, 11 Jan 1984 05:00:00 GMT
link: <https://www.wordpress-domein.nl/wp-json/>; rel="https://api.w.org/"
pragma: no-cache
server: Apache/2
set-cookie: PHPSESSID=d006046f5ee32450d79d8921dc07d625; path=/
status: 200
vary: Origin,Accept-Encoding,User-Agent
x-content-type-options: nosniff
x-robots-tag: noindex

# REQUEST HEADERS
:authority: www.wordpress-domein.nl
:method: GET
:path: /wp-json/wc/v3/orders/9299/?consumer_key=ck_e7619f16de7e3070f846c9b12blabla&consumer_secret=cs_9c7e612d493c02126093f66blabla
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9,nl;q=0.8
cache-control: no-cache
origin: http://localhost:8080
pragma: no-cache
referer: http://localhost:8080/orders
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 Edg/85.0.564.44
consumer_key: ck_e7619f16de7e3070f846c9bblabla
consumer_secret: cs_9c7e612d493c02126093f6blabla

en wat denk je... op sub.wordpress-domein.nl ... werkt het ook !!

code:

Request URL: https://www.wordpress-domein.nl/wp-json/wc/v3/orders/9299/?consumer_key=ck_e7619f16de7e3070f846c9b121blabla&consumer_secret=cs_9c7e612d493c02126093f6604blabla
Request Method: GET
Status Code: 200 
Remote Address: 83.172.180.91:443
Referrer Policy: no-referrer-when-downgrade

# RESPONSE HEADERS
access-control-allow-credentials: true
access-control-allow-headers: Authorization, Content-Type
access-control-allow-methods: OPTIONS, GET, POST, PUT, PATCH, DELETE
access-control-allow-origin: https://dashboard.wordpress-domein.nl
access-control-expose-headers: X-WP-Total, X-WP-TotalPages
allow: GET, POST, PUT, PATCH, DELETE
cache-control: no-transform, no-cache, no-store, must-revalidate
content-encoding: gzip
content-length: 1901
content-type: application/json; charset=UTF-8
date: Wed, 02 Sep 2020 07:31:19 GMT
expires: Wed, 11 Jan 1984 05:00:00 GMT
link: <https://www.wordpress-domein.nl/wp-json/>; rel="https://api.w.org/"
pragma: no-cache
server: Apache/2
set-cookie: PHPSESSID=0b388b96895c9255bc1d0c68344189ca; path=/
status: 200
vary: Origin,Accept-Encoding,User-Agent
x-content-type-options: nosniff
x-robots-tag: noindex

# REQUEST HEADERS
:authority: www.wordpress-domein.nl
:method: GET
:path: /wp-json/wc/v3/orders/9299/?consumer_key=ck_e7619f16de7e3070f846c9b121blabla&consumer_secret=cs_9c7e612d493c02126093f6604blabla
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9,nl-NL;q=0.8,nl;q=0.7,it;q=0.6
cache-control: no-cache
origin: https://dashboard.wordpress-domein.nl
pragma: no-cache
referer: https://dashboard.wordpress-domein.nl/login?redirect=%2F
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-site
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36
consumer_key: ck_e7619f16de7e3070f846c9b121blabla
consumer_secret: cs_9c7e612d493c02126093f6604blabla

En dan nu de zoektocht waarom het niet werkt als ik gebruik maak van de Axios of WC REST API (die ook gebruik maakt van Axios) repo's..

Man wat een feest!

[RoelZ]

Merethil schreef op woensdag 2 september 2020 @ 09:20:
Kan het zijn dat je URL niet resolved omdat er twee forward slashes staan in die URL (zie v3 // orders)?

code:

https://www.wordpress-domein.nl/wp-json/wc/v3//orders/?status=processing

Bij de andere twee heb je dat niet. Het is maar een idee, was het enige wat ik zo snel zag; helemaal geen response headers terugkrijgen vind ik ook vreemd.

@Merethil erg fijn dat je mee denkt! Alles is welkom namelijk, je weet maar nooit dat het zo iets lulligs (wat dan vaak het geval is) de oplossing gaat zijn.

In dit geval maakt het niet uit. Dit komt door de WC REST API repo, die bind die url samen waar ik zelf geen aanpassing kan doen. Als ik dit omzijl dan geeft hij (helaas) hetzelfde response... geen

[Woy]

RoelZ schreef op woensdag 2 september 2020 @ 09:35:
@Woy , bedankt voor me opnieuw te herinneren hoe eenvoudig het eigenlijk is
Maar goed dat je het doet, want jouw idee om even een basic example te proberen biedt me een nieuwe richting!

Conceptueel is het vrij eenvoudig, dat betekend niet dat het perse eenvoudig is om de exacte oorzaak te vinden. Maar het begint bij het begrip welke headers er bij welke requests gestuurd worden.

Ik heb het zojuist geprobeerd. Een simpele GET request naar mijn backend

Ik ken de libraries die je aanhaalt niet, maar zijn dat JS libraries die je op je dashboard gebruikt? Kijk dan eens bij die requests of de origin wel juist staat bij het request dat naar je backend gaat. Of misschien dat die libraries bewust een same-origin mode gebruiken?

[ Voor 4% gewijzigd door Woy op 02-09-2020 09:58 ]

[Tsjilp]

Weet niet of dit voor jou ook geldt, maar in het verleden ook last gehad van CORS issues icm axios, de oplossing voor mij was toen een default header mee te sturen

code:

'X-Requested-With': 'XMLHttpRequest'

Aangezien een normale httprequest wel werkt bij jou moet je het in de configuratie van axios zoeken.

[RoelZ]

Oké, mijn antwoord duurde even omdat ik met jullie laatste berichten nog even aan de slag wou.

@Woy het klopt dat de origin mist..
@Tsjilp deze toevoegen maakt geen verschil helaas..

De reden van deze korte antwoorden zijn eigenlijk door wat ik nu gevonden heb.
Wanneer ik geen gebruik maak van Headers (vanuit de request) gaan de GET requesten gewoon goed.
Hierbij maakt het niet uit of ik Axios of XMLHttpRequest vanuit Javascript gebruik.

Zodra ik ook maar een header toevoeg (op 'Content-Type: application/json' na), gaat het fout!
Dus ook als ik de 'X-Requested-With': 'XMLHttpRequest' toevoeg!

Het lijkt er nu op dat er toch vanuit Apache iets ingesteld staat wat mijn pogingen via PHP of .htaccess dwarsboomt.


Als ik onderstaand in mijn .htaccess zet, zie ik bijvoorbeeld dubbele headers

code:

<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
Header set Access-Control-Allow-Headers "origin, x-requested-with, content-type, authorization, x-requested-with"
Header set Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS"
Header always set Access-Control-Expose-Headers "Authorization, *"
</IfModule>

Response headers zijn dan

code:

access-control-allow-headers: Content-Type, Authorization, X-Requested-With
access-control-allow-headers: origin, x-requested-with, content-type, authorization, x-requested-with
access-control-allow-methods: GET, PUT, POST, DELETE, OPTIONS
access-control-allow-methods: PUT, GET, POST, DELETE, OPTIONS
access-control-allow-origin: *
access-control-allow-origin: *
access-control-expose-headers: Authorization, *
access-control-max-age: 1000
content-encoding: gzip
content-length: 35
content-type: application/json
date: Wed, 02 Sep 2020 18:03:48 GMT
server: Apache/2
status: 200
vary: Accept-Encoding,User-Agent

Om alles even los van de backend van Wordpress te krijgen heb ik nu een tijdelijk PHP bestandje gemaakt, zodat ik daar direct op kan vuren. Maar dus met dezelfde gekkigheden.

PHP:

<?php

header('Content-Type: application/json');
header("Access-Control-Allow-Origin: *");
header('Access-Control-Allow-Methods: GET, PUT, POST, DELETE, OPTIONS');
header('Access-Control-Max-Age: 1000');
header('Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With');

echo json_encode([
    'status' => 'ok'
]);

exit;

?>

Wederom weer clueless AF..

[kutagh]

CORS preflight is niet iets wat op elk request wordt toegepast. Als er aan bepaalde criteria zijn voldaan, wordt een request zonder CORS preflight gewoon naar de server gestuurd, zie ook https://developer.mozilla..._access_control_scenarios

[Barryvdh]

Ik zou ook denken aan Preflight. Bij complexe requests (dus met meer headers bijvoorbeeld) doet hij eerst een OPTIONS request. Je ziet deze volgens mij standaard niet in Chrome, maar kan je wel aanzetten: https://stackoverflow.com...s-requests-in-network-tab

You'll need to go to: chrome://flags/#out-of-blink-cors, disable the flag, and restart Chrome.

Krijg je daar wel een goede response op? Wellicht dat de server die blokkeert?
(Of volgens het antwoord van de ontwikkelaar wellicht niet meer nodig, maar dan moet je even kijken of je OPTIONS requests ziet)

[ Voor 11% gewijzigd door Barryvdh op 02-09-2020 20:27 ]

[RoelZ]

Ik zal eens meer gaan duiken in die OPTIONS preflight request dan. Zoals ik het ook nu lees in jullie antwoorden lijkt het erop dat dit nog niet goed of volledig is.
Waarschijnlijk dat ik dan ook automatisch @Woy zijn vraag beantwoord krijgen. De Origin header mist nu nog namelijk.


@Barryvdh , thanks voor deze tip! Ik dacht even dat je refereerde naar het uitzetten van CORS in de browser, maar ken ik nog niet en kan me wel helpen bij het debuggen!

[xh3adshotx]

RoelZ schreef op woensdag 2 september 2020 @ 20:06:
De reden van deze korte antwoorden zijn eigenlijk door wat ik nu gevonden heb.
Wanneer ik geen gebruik maak van Headers (vanuit de request) gaan de GET requesten gewoon goed.
Hierbij maakt het niet uit of ik Axios of XMLHttpRequest vanuit Javascript gebruik.

Zodra ik ook maar een header toevoeg (op 'Content-Type: application/json' na), gaat het fout!
Dus ook als ik de 'X-Requested-With': 'XMLHttpRequest' toevoeg!

Het lijkt er nu op dat er toch vanuit Apache iets ingesteld staat wat mijn pogingen via PHP of .htaccess dwarsboomt.

Wederom weer clueless AF..

De header "Content-Type" is een CORS-safelisted header, deze wordt dus met een paar restricties standaard toegestaan op de server. Als die header wél werkt en het niet werkt op het moment dat je extra headers toe gaat voegen lijkt het erop alsof je custom access-control headers niet goed doorkomen. Heb je al eens met Fiddler gekeken wat de exacte request/response op de preflight en daadwerkelijke request is? Dat vind ik altijd iets duidelijker dan de developer tools want die kloppen niet 100% van de tijd qua headers.

Edit: doordat je "access-control-max-age" gebruikt met een waarde van "1000" moet je ongeveer 17 minuten wachten als je een wijziging maakt voordat je het resultaat zult zien. Tenzij je een incognito venster gebruikt die je steeds sluit/opent. Deze cached namelijk de preflight response.

[ Voor 8% gewijzigd door xh3adshotx op 03-09-2020 09:18 ]

[RoelZ]

Even voor de volledigheid. Mijn basic CORS opzet aan de ontvangende kant

PHP:

<?php

header('Content-Type: application/json');
header("Access-Control-Allow-Origin: *");
header('Access-Control-Allow-Methods: GET, PUT, POST, DELETE, OPTIONS');
header('Access-Control-Max-Age: 1000');
header('Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With');

echo json_encode([
    'status' => 'ok'
]);

exit;

?>

Belangrijk: geen .htaccess ingesteld mbt Headers


GOED: Optie 1 - Simple requests:

JavaScript:

const xhr = new XMLHttpRequest();
xhr.open('GET', 'https://www.wordpress-domein.nl/cors.php');
xhr.send(); 

Request:

Origin: http://localhost:8080

Response:

access-control-allow-origin: *

FOUT: Optie 2 - Preflighted requests:

JavaScript:

xhr.open('POST', url);
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.onreadystatechange = this.debugger;
xhr.send('{status:ok}');

Note: ik heb dit ook op dezelfde wijze met een GET geprobeerd
Request: Geen Origin header
Response: Geen response
Console error:

Access to XMLHttpRequest at 'https://www.wordpress-domein.nl/cors.php' from origin 'http://localhost:8080' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Over de OPTIONS:

The browser determines that it needs to send this based on the request parameters that the JavaScript code snippet above was using, so that the server can respond whether it is acceptable to send the request with the actual request parameters.

Wat ik vervolgens ook in dezelfde MDN docs bij Preflight requests and redirects terug vindt is het volgende

However, if the request is one that triggers a preflight due to the presence of the Authorization header in the request, you won’t be able to work around the limitation using the steps above. And you won’t be able to work around it at all unless you have control over the server the request is being made to.

Op dit moment doe ik enkel een POST/GET met twee additionele headers... en ben ik nog niet eens zo ver als een Authorizatie header.

Als iemand me kan helpen met iets meer begrip bij dit hoofdstuk (Preflight requests and redirects), zou me dat denk ik echt helpen.

[xh3adshotx]

RoelZ schreef op donderdag 3 september 2020 @ 09:20:

PHP:

<?php

header('Content-Type: application/json');
header("Access-Control-Allow-Origin: *");
header('Access-Control-Allow-Methods: GET, PUT, POST, DELETE, OPTIONS');
header('Access-Control-Max-Age: 1000');
header('Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With');

echo json_encode([
    'status' => 'ok'
]);

exit;

?>

FOUT: Optie 2 - Preflighted requests:

JavaScript:

xhr.open('POST', url);
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.onreadystatechange = this.debugger;
xhr.send('{status:ok}');

Note: ik heb dit ook op dezelfde wijze met een GET geprobeerd
Request: Geen Origin header
Response: Geen response
Console error:

Access to XMLHttpRequest at 'https://www.wordpress-domein.nl/cors.php' from origin 'http://localhost:8080' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Je mist sowieso de "X-PINGOTHER" header aan de PHP kant. Check eens met Fiddler wat exact verstuurd/ontvangen wordt.

[Tsjilp]

Nog een gokje: je response is altijd

code:

echo json_encode([
    'status' => 'ok'
]);

Terwijl een options request een lege response verwacht?

[n9iels]

RoelZ schreef op donderdag 3 september 2020 @ 09:20:
Even voor de volledigheid. Mijn basic CORS opzet aan de ontvangende kant

PHP:

<?php

header('Content-Type: application/json');
header("Access-Control-Allow-Origin: *");
header('Access-Control-Allow-Methods: GET, PUT, POST, DELETE, OPTIONS');
header('Access-Control-Max-Age: 1000');
header('Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With');

echo json_encode([
    'status' => 'ok'
]);

exit;

?>

Probeer in plaats van 'ok' eens het request type terug te geven? Dus $_SERVER['REQUEST_METHOD']. En vuur er dan eens via Postman een GET, POST en OPTIONS op af.

Ik zat net zelf even te rommelen en in mijn geval gaven de rewrite rules in de .htaccess problemen. Alle request die binnen komen redirect ik namelijk naar de domeinnaam met www ervoor. Een OPTIONS request krijgt dan dus wellicht een 301 als status code. Daarnaast deed mijn .htaccess nog iets waardoor de requests (denk ik) via de index.php werden afgehandeld. Een POST request kwam daardoor als GET request binnen.

[ Voor 15% gewijzigd door n9iels op 03-09-2020 10:53 ]

[RoelZ]

Huidige setup

Om de context even up-to-date te houden.

cors.php

PHP:

header('Content-Type: application/json');
header("Access-Control-Allow-Origin: *");
header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
/* header('Access-Control-Max-Age: 1000'); */
header('Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With', 'X-PINGOTHER');

echo json_encode([
    'status' => $_SERVER['REQUEST_METHOD']
]);

exit;

.htaccess

code:

#<IfModule mod_headers.c>
# Header add Access-Control-Allow-Origin "*"
# Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type, authorization, x-requested-with"
# Header add Access-Control-Allow-Methods "GET, POST, OPTIONS"
# Header always add Access-Control-Expose-Headers "Authorization, *"
#</IfModule>

.

Fiddler

@xh3adshotx , thanks voor de tip van Fiddler. Ik probeer nu echter al het laatste half uur Fiddler onder de knie te krijgen.. gezien ik een vreemd resultaat krijg als ik het check vanuit Live traffic (ik heb de XMLHttpRequest() nu achter een knop). Fiddler toont me de call, maar het response en request zijn (voor mij) erg onduidelijk.


Als ik via de Composer optie een call doe krijg ik een Forbidden


Ik heb overigens de X-PINGOTHER toegevoegd aan de PHP headers, zonder merkbaar verschil helaas.

@Tsjilp & @n9iels , ik heb de 'ok' nu veranderd in de REQUEST_METHOD, en hij geeft me nu dus een JSON met { status: GET } terug (afhankelijk van mijn method uiteraard. Maar ik denk dat dit response eigenlijk niet zou uitmaken.
Hoe bedoel je dat de OPTIONS een leeg repsonse verwacht? Is dit niet het response dat uiteindelijk (na correcte preflight) het response zou moeten/mogen zijn?

@n9iels , jouw bevindingen mbt de POST op een CORS test icm de .htaccess headers zijn gelijk aan die van mij dan... (gelukkig).
Als ik alles uitzet (wat ik nu dus deze ochtend telkens heb gedaan) werkt een normale GET. Zet ik deze aan, gaat dit fout omdat er dan twee keer headers geset worden.

code:

access-control-allow-headers: Content-Type, Authorization, X-Requested-With
access-control-allow-methods: GET, POST, OPTIONS
access-control-allow-methods: GET, POST, OPTIONS
access-control-allow-origin: *
access-control-allow-origin: *

Ik maak dus ook gebruik van de add ipv set

Header add Access-Control-Allow-Methods "GET, POST, OPTIONS"

Maar bij gebruik van set gaat het op dezelfde manier fout en zie ook dubbele headers.

.

Postman

Voor Postman (een tool die ik zelf vaker gebruik) werkt elke request wel naar behoren. Maar dat heeft het ook altijd gedaan.

[xh3adshotx]

RoelZ schreef op donderdag 3 september 2020 @ 11:34:

Huidige setup

Om de context even up-to-date te houden.

cors.php
[php]
header('Content-Type: application/json');
header("Access-Control-Allow-Origin: *");
header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
/* header('Access-Control-Max-Age: 1000'); */
header('Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With', 'X-PINGOTHER');

echo json_encode([
'status' => $_SERVER['REQUEST_METHOD']
]);

Je "Access-Control-Allow-Headers" lijkt fout. Ik ben geen PHP programmeur maar volgens mij is in dit geval de "," verkeerd geplaatst waardoor het een replace zou worden volgens de documentatie aangezien PHP niet type safe is een een string altijd true is. Volgens mij moet het in plaats van dit:

PHP:

header('Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With', 'X-PINGOTHER');

Dit zijn

PHP:

header('Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With, X-PINGOTHER');

Ik zou ook de dubbele entries uit de HTACCESS weghalen, dingen dubbel sturen is (bijna) nooit een goed idee in dit geval.

RoelZ schreef op donderdag 3 september 2020 @ 11:34:

Fiddler

@xh3adshotx , thanks voor de tip van Fiddler. Ik probeer nu echter al het laatste half uur Fiddler onder de knie te krijgen.. gezien ik een vreemd resultaat krijg als ik het check vanuit Live traffic (ik heb de XMLHttpRequest() nu achter een knop). Fiddler toont me de call, maar het response en request zijn (voor mij) erg onduidelijk.
[Afbeelding]

Aangezien je via https werkt is dit scherm van Fiddler niet heel nuttig zonder dat je Fiddler instelt om https verkeer te onderscheppen.

RoelZ schreef op donderdag 3 september 2020 @ 11:34:

Postman

Voor Postman (een tool die ik zelf vaker gebruik) werkt elke request wel naar behoren. Maar dat heeft het ook altijd gedaan.
[Afbeelding]

[Afbeelding]

Postman is geen browser. CORS is iets wat een browser handhaaft voor de veiligheid. Dingen als CURL/Postman/whatever zullen daar niets mee doen.

[ Voor 15% gewijzigd door xh3adshotx op 03-09-2020 12:15 ]

[RoelZ]

@xh3adshotx thanks voor je snelle reply.

Goed gezien van de typo in mijn php bestand.
Ik heb dit aangepast en krijg nu (heel vreemd) twee requesten te zien in mijn devtools, waarin de tweede naar een 405 refereert voor de OPTIONS method.

Dit is dus een POST request naar mijn cors.php

JavaScript:

xhr.open('POST', url);
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.send('{}'); 

request header (maar geen response)

code:

Provisional headers are shown
Content-Type: application/json
Referer: http://localhost:8080/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 Edg/85.0.564.44
X-PINGOTHER: pingpong

De tweede call

code:

:authority: www.wordpress-domein.nl
:method: OPTIONS
:path: /api/v2/cors.php
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9,nl;q=0.8
access-control-request-headers: content-type,x-pingother
access-control-request-method: POST
cache-control: no-cache
origin: http://localhost:8080
pragma: no-cache
referer: http://localhost:8080/
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 Edg/85.0.564.44

Ik heb dus géén .htacess headers aanstaan! Ik had deze gecomment (zie vorige post code)
Die dubbele kwamen alleen vreemd genoeg naar voren als ik mijn eigen (enkele) headers aanzet.

En mijn cors.php ziet er nu zo uit

PHP:

header('Content-Type: application/json');
header("Access-Control-Allow-Origin: *");
header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
header('Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With, X-PINGOTHER');

echo json_encode([
    'status' => $_SERVER['REQUEST_METHOD']
]);

exit;

Is had de HTTPS in Fiddler inderdaad aangezet, maar tevergeefs dezelfde melding.

En goed dat je het benadrukt dat Postman geen browser is en CORS vanuit browsers geinitieerd wordt.
Dit was me inderdaad ook al duidelijk, maar wou graag antwoord geven op de eerdere vraag van @n9iels

[ Voor 5% gewijzigd door RoelZ op 03-09-2020 12:32 . Reden: Aanvulling nav @xh3adshotx's reply ]

[xh3adshotx]

RoelZ schreef op donderdag 3 september 2020 @ 12:28:
[Afbeelding]

Lijkt erop dat de "Access-Control-Allow-Origin" header dus niet goed doorkomt. Kan je eens proberen om "Authorization" uit je "Access-Control-Allow-Headers" te halen? Deze kan namelijk nog voor wat raar gedrag zorgen aangezien "Authorization" het gedrag van de andere policies beïnvloed.

RoelZ schreef op donderdag 3 september 2020 @ 12:28:
Is had de HTTPS in Fiddler inderdaad aangezet, maar tevergeefs dezelfde melding.

Als dat vinkje aanstaat en je het root certificate geïnstalleerd hebt in Chrome/FireFox en/of de Windows certificate store (afhankelijk van de browser) zou je de inhoud van de requests moeten zien.

[RoelZ]

Dat zorgt ervoor dat er maar 1 call gedaan wordt

code:

Provisional headers are shown
Content-Type: application/json
Referer: http://localhost:8080/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 Edg/85.0.564.44
X-PINGOTHER: pingpong

En dus hetzelfde als de vorige

cors.php

PHP:

header('Content-Type: application/json');
header("Access-Control-Allow-Origin: *");
header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
/*header('Access-Control-Max-Age: 1000');*/
header('Access-Control-Allow-Headers: Content-Type, X-Requested-With, X-PINGOTHER');

echo json_encode([
    'status' => $_SERVER['REQUEST_METHOD']
]);

exit;

[inTIMidate]

Heb je al geprobeerd om geen reponse terug te geven in geval van een OPTIONS request, maar alleen headers?

[418O2]

inTIMidate schreef op vrijdag 4 september 2020 @ 10:21:
Heb je al geprobeerd om geen reponse terug te geven in geval van een OPTIONS request, maar alleen headers?

En status 200, niet onbelangrijk

[Barryvdh]

418O2 schreef op vrijdag 4 september 2020 @ 10:22:
[...]

En status 200, niet onbelangrijk

Nouja, als je alleen headers stuurt dan is een 204 natuurlijk beter. En 204 zonder body is inderdaad prima voor preflights.

[RoelZ]

Thanks voor de tip. Ik zal dit eens uit gaan proberen!

[RoelZ]

@inTIMidate , is dit wel mogelijk?

Zover ik PHP begrijp kan ik alleen controleren op GET of POST.
Het terug geven van alleen de Headers (en dus geen JSON oid) geeft helaas hetzelfde resultaat.


Voor iedereen die dit nog leest , ik ben inmiddels de moed (wederom) op aan het geven.
Het blijft zo vreemd dat ik de enige ben die hier tegen aan loopt.
Dit icm dezelfde requests naar een andere server te doen die verder qua software identiek is en het hier wel werkt, maakt dit voor mij uitermate frustrerend en ben ik inmiddels bereid om bij de hosting provider weg te gaan en de gehele productie omgeving over te gaan huizen.

Mochten jullie toch nog tips hebben of met mij willen sparren, dan hoor ik dit uiteraard erg graag!

Ik wil wel iedereen hier ontzettend bedanken voor alle bereidheid en tips! Dit heb ik echt enorm gewaardeerd!

[mrdemc]

RoelZ schreef op donderdag 10 september 2020 @ 15:57:
@inTIMidate , is dit wel mogelijk?

Zover ik PHP begrijp kan ik alleen controleren op GET of POST.
Het terug geven van alleen de Headers (en dus geen JSON oid) geeft helaas hetzelfde resultaat.


Voor iedereen die dit nog leest , ik ben inmiddels de moed (wederom) op aan het geven.
Het blijft zo vreemd dat ik de enige ben die hier tegen aan loopt.
Dit icm dezelfde requests naar een andere server te doen die verder qua software identiek is en het hier wel werkt, maakt dit voor mij uitermate frustrerend en ben ik inmiddels bereid om bij de hosting provider weg te gaan en de gehele productie omgeving over te gaan huizen.

Mochten jullie toch nog tips hebben of met mij willen sparren, dan hoor ik dit uiteraard erg graag!

Ik wil wel iedereen hier ontzettend bedanken voor alle bereidheid en tips! Dit heb ik echt enorm gewaardeerd!

Een OPTIONS requests komt over het algemeen niet verder dan de webserver zelf. Jouw PHP wijzigingen zullen daar dus geen invloed op hebben tenzij je de webserver zo instelt dat deze de OPTIONS requests ook moet doorverwijzen naar een script-handler. Om het zeker te weten zou je

1. in je php.ini expose_php aan kunnen zetten:
   
   code:
   

   expose_php = On

   
   Deze header zou je dan ook in je OPTIONS moeten zien.
2. of doe een options-request naar een apart php-bestand waarin je deze code hebt staan:
   
   code:
   

   <?php
   file_put_contents('BUITEN DE WEBROOT\file.txt', print_r($_SERVER, TRUE) );
   ?>

   
   en open die om te kijken welke headers je ziet staan.

Je zou dan in ieder geval

code:

$_SERVER['REQUEST_METHOD'] = options

moeten hebben staan daar. Als dat het geval is weet je zeker dat de OPTIONS request naar PHP wordt omgeleid en zit het probleem inderdaad ergens anders, zo nee dan zul je de webserver configuratie moeten nalopen. Ik krijg namelijk uit bovenstaande thread nog niet helemaal duidelijk of dat wel goed staat allemaal qua instellingen en gezien de output ook die je te zien krijgt (o.a. de "405: Method not allowed" wat dus betekent dat jouw webserver teruggeeft: Je mag geen OPTIONS request uitvoeren op deze server).

[ Voor 3% gewijzigd door mrdemc op 10-09-2020 17:16 ]

[RoelZ]

@mrdemc , thanks! Dit geeft mij al meer zicht!

In dit geval jou opties geprobeerd vanuit Postman
Een OPTIONS request naar jouw optie 2 beide servers (dev/prod elk onder andere host) geeft mij het volgende resultaat.

dev: 200 met een lege pagina als resultaat


prod: 405 met een default server 405 pagina



Een OPTIONS request (met Postman) naar mijn eerdere cors demo bestand, geeft ook alleen in het geval van dev wel "method": "OPTIONS" terug. In het geval van prod, de default 405.


Zegt dit jou iets? Betekent dit dat ik toch echt bij de php.ini moet kunnen om dit te veranderen?

FYI: Productie staat nu bij 123-webhost, Development bij Vimexx..

[418O2]

405 betekent dat options niet mag. Zit dus in je config

[RoelZ]

Bedoel je met config, de php.ini en zo ja wat dan? Wat @mrdemc aangeeft bij optie 1? Of (nog) iets anders?

Of moet ik bij apache conf zijn en zo ja wat dan?

[ Voor 0% gewijzigd door RoelZ op 10-09-2020 23:40 . Reden: Typo ]

[mrdemc]

RoelZ schreef op donderdag 10 september 2020 @ 23:06:
@mrdemc , thanks! Dit geeft mij al meer zicht!

In dit geval jou opties geprobeerd vanuit Postman
Een OPTIONS request naar jouw optie 2 beide servers (dev/prod elk onder andere host) geeft mij het volgende resultaat.

dev: 200 met een lege pagina als resultaat
[Afbeelding]

prod: 405 met een default server 405 pagina
[Afbeelding]


Een OPTIONS request (met Postman) naar mijn eerdere cors demo bestand, geeft ook alleen in het geval van dev wel "method": "OPTIONS" terug. In het geval van prod, de default 405.


Zegt dit jou iets? Betekent dit dat ik toch echt bij de php.ini moet kunnen om dit te veranderen?

FYI: Productie staat nu bij 123-webhost, Development bij Vimexx..

Je kunt de php.ini weer terugzetten met de expose off.

Het is dus inderdaad de webserver die het tegenhoudt. Als je een .htaccess bestand hebt kun je kijken of je het kunt oplossen door deze regels bij de rewrite rules te plaatsen:

code:

RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|OPTIONS|POST) [NC]
RewriteRule .* - [F,L]

Waarbij je in de lijst van methods wel even rekening moet houden met alles wat je dus nu ook al aan hebt staan. Ook moet je rekening houden met de flags [F,L] op het einde in relatie tot de andere regels. Let op: bij een verkeerde configuratie kan het zijn dat de website offline gaat. Je wilt dit dus misschien eerst proberen op een test subdomein/sub folder o.i.d.

Als dat niet werkt zul je je hoster moeten vragen of ze het aan willen passen.

[ Voor 4% gewijzigd door mrdemc op 11-09-2020 00:25 ]

[RoelZ]

@mrdemc bedankt voor deze tip! Dit ga ik straks even proberen.

Nog wel even een belangrijk gegeven wat ik niet duidelijk heb gemeld.

Het is bij 123 webhost niet mogelijk om de php.ini te wijzigen ivm shared hosting. Dus heb ik jou optie 1 ook niet toegepast in mijn vorige berichten.

Maakt dit jou inzicht tot jouw laatste antwoord dan anders of kan ik dit alsnog proberen?

[mrdemc]

RoelZ schreef op vrijdag 11 september 2020 @ 08:44:
@mrdemc bedankt voor deze tip! Dit ga ik straks even proberen.

Nog wel even een belangrijk gegeven wat ik niet duidelijk heb gemeld.

Het is bij 123 webhost niet mogelijk om de php.ini te wijzigen ivm shared hosting. Dus heb ik jou optie 1 ook niet toegepast in mijn vorige berichten.

Maakt dit jou inzicht tot jouw laatste antwoord dan anders of kan ik dit alsnog proberen?

Geen probleem. Als je dan voor optie 2 bent gegaan heeft het php script als het goed is een bestand aangemaakt. Heb je dat kunnen verifiëren ook? Als er geen bestand staat is hetgeen wat ik zei inderdaad het geval. Als er wel een bestand staat met die naam zou je even moeten kijken naar de request_method die je dan in dat bestand ziet staan.

[RoelZ]

Ah, dan begrijp ik nu iets beter wat je probeerde te doen.

Ik weet dan alleen niet welk path ik hier moet invullen?

code:

'BUITEN DE WEBROOT\file.txt'

Is dit dan vanuit de document root van mijn server?

Bijv. /domains/domeinnaam.nl
Of moet ik nog dieper? Ik heb namelijk alleen rechten tot aan die /domains

[mrdemc]

RoelZ schreef op vrijdag 11 september 2020 @ 09:29:
Ah, dan begrijp ik nu iets beter wat je probeerde te doen.

Ik weet dan alleen niet welk path ik hier moet invullen?

code:

'BUITEN DE WEBROOT\file.txt'

Is dit dan vanuit de document root van mijn server?

Bijv. /domains/domeinnaam.nl
Of moet ik nog dieper? Ik heb namelijk alleen rechten tot aan die /domains

Afhankelijk van waar je het bestand plaatst kun je ook relatief gaan. Stel je plaatst het bestand in je webroot (domein.nl/bestand.php) dan kun je als pad ../bestand.txt gebruiken. In de omgeving van de webhost zou je dan dat bestand kunnen vinden in de map die 1 hoger dan je webroot staat.

[Woy]

@RoelZ dat haalt niet zo heel veel uit, het mag op een willekeurige plek, maar je wil die informatie niet publiek beschikbaar hebben, dus vandaar buiten de webroot.

[RoelZ]

Duidelijk! Thanks voor deze opheldering!

Ik zie dat hij het bestand wel heeft aangemaakt.
Houdt dit nu dan in dat de server toch wel goed is ingesteld....?

code:

Array
(
    [USER] => webhostuser
    [HOME] => /home/webhostuser
    [SCRIPT_NAME] => /api/v2/options.php
    [REQUEST_URI] => /api/v2/options.php
    [QUERY_STRING] => 
    [REQUEST_METHOD] => GET
    [SERVER_PROTOCOL] => HTTP/2.0
    [GATEWAY_INTERFACE] => CGI/1.1
    [REMOTE_PORT] => 51361
    [SCRIPT_FILENAME] => /home/webhostuser/domains/domein.com/private_html/api/v2/options.php
    [SERVER_ADMIN] => [e-mail]
    [CONTEXT_DOCUMENT_ROOT] => /home/webhostuser/domains/domein.com/private_html
    [CONTEXT_PREFIX] => 
    [REQUEST_SCHEME] => https
    [DOCUMENT_ROOT] => /home/webhostuser/domains/domein.com/private_html
    [REMOTE_ADDR] => XX.XXX.XX.XXX
    [SERVER_PORT] => 443
    [SERVER_ADDR] => XX.XXX.XXX.XX
    [SERVER_NAME] => www.domein.com
    [SERVER_SOFTWARE] => Apache/2
    [SERVER_SIGNATURE] => 
    [LD_LIBRARY_PATH] => /usr/lib/apache
    [PATH] => /sbin:/usr/sbin:/bin:/usr/bin
    [HTTP_HOST] => www.domein.com
    [HTTP_COOKIE] => et-pb-recent-items-font_family=Marck%20Script%7CRoboto; wp-settings-time-1=1599561243; wp-settings-1=editor%3Dtinymce%26libraryContent%3Dbrowse%26imgsize%3Dfull; et-pb-recent-items-colors=%23d6d6d6%7C%23ffffff%7C%23000000%7C%23dfbe6a%7Crgba(224%2C153%2C0%2C0)%7C%23d8ae46%7C%23e09900%7C%238300e9; pll_language=en; PHPSESSID=een_uuid
    [HTTP_ACCEPT_LANGUAGE] => en-US,en;q=0.9,nl-NL;q=0.8,nl;q=0.7,it;q=0.6
    [HTTP_ACCEPT_ENCODING] => gzip, deflate, br
    [HTTP_SEC_FETCH_DEST] => document
    [HTTP_SEC_FETCH_USER] => ?1
    [HTTP_SEC_FETCH_MODE] => navigate
    [HTTP_SEC_FETCH_SITE] => none
    [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    [HTTP_USER_AGENT] => Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36
    [HTTP_UPGRADE_INSECURE_REQUESTS] => 1
    [HTTP_CACHE_CONTROL] => max-age=0
    [proxy-nokeepalive] => 1
    [H2_STREAM_TAG] => 11-5
    [H2_STREAM_ID] => 5
    [H2_PUSHED_ON] => 
    [H2_PUSHED] => 
    [H2_PUSH] => on
    [H2PUSH] => on
    [HTTP2] => on
    [SSL_TLS_SNI] => www.domein.com
    [HTTPS] => on
    [GEOIP_LONGITUDE] => 4.899500
    [GEOIP_LATITUDE] => 52.382401
    [GEOIP_AREA_CODE] => 0
    [GEOIP_METRO_CODE] => 0
    [GEOIP_DMA_CODE] => 0
    [GEOIP_COUNTRY_NAME] => Netherlands
    [GEOIP_COUNTRY_CODE] => NL
    [GEOIP_CONTINENT_CODE] => EU
    [GEOIP_ADDR] => XX.XXX.XX.XXX
    [UNIQUE_ID] => X1qSkI@zlVg2oy-9lcitywAAAAU
    [FCGI_ROLE] => RESPONDER
    [PHP_SELF] => /api/v2/options.php
    [REQUEST_TIME_FLOAT] => 1599771280.3457
    [REQUEST_TIME] => 1599771280
)

Wellicht iets te snel gedropt hier, maar dit wordt dus alleen aangemaakt als ik een GET of POST doe, en dus niet bij OPTIONS.

Dit alles vanuit Postman btw.

Dus ik denk dat ik dan nu aan jou eerdere oplossing ga beginnen @mrdemc

[ Voor 4% gewijzigd door RoelZ op 11-09-2020 09:58 ]

[mrdemc]

RoelZ schreef op vrijdag 11 september 2020 @ 09:50:
Duidelijk! Thanks voor deze opheldering!

Ik zie dat hij het bestand wel heeft aangemaakt.
Houdt dit nu dan in dat de server toch wel goed is ingesteld....?

code:

Array
(
    [REQUEST_URI] => /api/v2/options.php
    [REQUEST_METHOD] => GET
)

Wellicht iets te snel gedropt hier, maar dit wordt dus alleen aangemaakt als ik een GET of POST doe, en dus niet bij OPTIONS.

Dit alles vanuit Postman btw.

Dus ik denk dat ik dan nu aan jou eerdere oplossing ga beginnen @mrdemc

Nope, zoals je ziet is de request_method die geregistreerd is een 'GET' request, geen OPTIONS. Als je het PHP bestand aanpast naar dit en dan nogmaals een OPTIONS uitvoert en dan nog even kijkt of het bestand is aangepast:

PHP:

<?php
$line = $_SERVER['REQUEST_TIME'] . ' - ' . $_SERVER['REQUEST_METHOD'] . "\r\n";
file_put_contents('BUITEN DE WEBROOT\request.txt', $line, FILE_APPEND );
?>

dat werkt misschien wat meer overzichtelijker (meer als een logboek).

[ Voor 54% gewijzigd door mrdemc op 11-09-2020 10:13 ]

[RoelZ]

@mrdemc , dit geeft hetzelfde resultaat maar inderdaad hierdoor iets overzichtelijker.
GET en POST loggen dus gewoon, OPTIONS niet.

Ik ben nu bezig om jouw voorstel in mijn .htaccess te zetten en me in aan het lezen over de flags.
Echter merk ik dat ik hier tegen mijn kennis over Rewrite rules aanloop.

In jouw voorstel staat (als vb) .* op F (forbidden) en L (direct stoppen).

code:

RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|OPTIONS|POST) [NC]
RewriteRule .* - [F,L]

Nu begrijp ik dat dit een voorbeeld is, maar om eerlijk te zijn weet ik niet hoe ik dit icm mijn huidige .htaccess regels doe.

Heb je hier wellicht een idee? Al is het maar om te testen of OPTIONS hierdoor wel toegankelijk wordt.

code:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

[mrdemc]

Ja hoor, hieronder de .htaccess zoals ik verwacht dat het zou moeten werken:

code:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_METHOD} !^(GET|OPTIONS|HEAD|POST) [NC]
RewriteRule .* - [F,L]

RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

[RoelZ]

Thanks! Aangepast, maar tevergeefs... hetzelfde resultaat wanneer ik met Postman een OPTIONS request probeer uit te oefenen op het php-bestand. Een 405 dus en logischerwijs geen logging erbij..

Dan zou ik bij 123-webhost moeten aankloppen als ik jou eerdere uitleg goed begrijp.
Hoe en wat zou ik de hoster in dit geval dan moeten vragen te veranderen?

[418O2]

Ik zou gewoon even aangeven dat de webserver je options requests bij asynchrone communicatie dienst weigert.

Ik gok dat het wel bekend is

[RoelZ]

Thanks @418O2 , ik had de vraag zojuist al opgesteld. Dit ga ik dan ook nu versturen.

[RoelZ]

Houston, we have lift off!

1599812121 - POST
1599817005 - OPTIONS

Nu de OPTIONS request wordt toegelaten zou eigenlijk mijn initiele probleem direct opgelost moeten zijn, zo ik dacht... maar dat blijkt nog niet direct zo te zijn.

Ik ga dus even al mijn code na lopen en laat jullie mijn bevindingen nog wel weten!

[RoelZ]

Update #3

Ondanks dat ik de applicatie waar ik dit voor aan het uitzoeken ben nog niet aan de praat heb, is het me inmiddels wel gelukt om een GET en POST te versturen middels JavaScript XMLHttpRequest (xhr) !
Waarin ik hier eerder faalde... gaat dit nu dus goed! 🎉

Echt zo blij als een kind nu!

Nu is het alleen nog uitzoeken waarom Axios mijn requests naar de WP-JSON niet toelaat (Bearer Auth), terwijl deze wel lukken via een reguliere GET request naar dezelfde locatie met key & secret params.

Ongelofelijk dat ik zo ver ben gekomen... ik had het al zoo vaak opgegeven haha!
Ik moet ook even gaan nadenken hoe ik hier nu het beste antwoord uit selecteer. @Woy , misschien ideeën?

[RoelZ]

Alright, mijn initiele vraag is verholpen! (een groot feest!)
Ik heb eindelijk de CORS issue aan de kant van mijn productie omgeving opgelost en de applicatie die stand-alone gehost staat op een ander domein gerechtigd gekregen om alle data op te halen vanuit productie.

Om een toekomstige Tweaker te helpen in dit probleem probeer ik het hieronder zo duidelijk mogelijk op te sommen aan checks en wat uiteindelijk geleid heeft naar mijn oplossing, alhoewel hier vrijwel niemand tegen aan zal lopen.

Het initiele probleem

Access to XMLHttpRequest at 'https://www.wordpress-domein.nl/wp-json/wc/v3/orders/?status=processing' from origin 'https://sub.wordpress-domein.nl' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Een error log in de Console van mijn Devtools gaf dus aan dat er een bepaalde policy gehanteerd werd op de server waar gegevens vandaan gehaald moesten worden.
Kortom: Het domein vanwaar de aanvraag kwam werd niet geaccepteerd. (ook wel: cross-domain issue)

Iets wat dan vrijwel altijd geroepen wordt is:

"Zet de Access-Control-Allow-Headers: aan en op *"

Maar hiermee zet je (logisch) de deur open voor ieder domein. Dus ook andere die even een localhost richten op jouw server zouden dan potentieel bij je gegevens kunnen.

Nu kun je dit dus vrij eenvoudig de asterix (*) zetten op het domein vanuit waar je het request gaat doen.
Houdt er dan rekening mee dat je eventuele andere domeinen blokkeert, mocht je die ook toegang willen bieden.

Het setten van deze header kun je op verschillende manieren mogelijk maken.

1. In het geval van Apache, in je .htaccess

code:

<IfModule mod_headers.c>
Header add Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Methods "GET, POST, OPTIONS"
Header add Access-Control-Allow-Headers "origin, content-type, x-requested-with"
</IfModule>

2. In het geval van PHP, in het bestand dat wordt aangeroepen wanneer de data wordt opgevraagd.
In mijn geval draai ik de Wordpress REST API en komt hier de functions.php er tussendoor.

PHP:

if (isset($_SERVER['HTTP_ORIGIN'])) {
  $http_origin = $_SERVER['HTTP_ORIGIN'];
    
  if ($http_origin == "http://localhost:8080" || $http_origin == "https://www.mijnanderedomein.com")
  {
    header('Content-Type: application/json');
    header("Access-Control-Allow-Origin: *");
    header('Access-Control-Allow-Methods: GET, POST, OPTIONS'); 
    header('Access-Control-Allow-Headers: Content-Type, X-Requested-With');
  }
}

Normaliter zou dit al de oplossing zijn, ware het niet dat in mijn geval de server (Apache.conf of PHP.ini) zo ingesteld was dat het de OPTIONS request tegen hield en daardoor de Preflight check faalde, waardoor vervolgens mijn Requests alsnog geweigert bleven.

Door onderstaande toe te voegen aan de .htaccess kon ik er zeker van zijn dat een OPTIONS request naar een zelfgeschreven test bestand mij toe zou moeten laten.
Dit staat los van de CORS headers, maar dus puur een OPTIONS request op een bestand.

code:

RewriteCond %{REQUEST_METHOD} !^(GET|OPTIONS|HEAD|POST) [NC]
RewriteRule .* - [F,L]

Dit gaf me voor het eerst een ander result dan voor heen. Namelijk de 405, Method not allowed.
Hiermee werd het duidelijk dat het wel bij de server moest liggen. De hostpartij had dit aangepast in hun configuratie en daarmee kon ik dan eindelijk normaal gebruik maken van API calls vanuit een ander domein.


Graag wil iedereen in deze thread bedanken en met name @Anoniem: 882605 @n9iels @xh3adshotx @Woy en @mrdemc

[mrdemc]

Fijn dat je het hebt kunnen oplossen! Ook complimenten voor het posten van de oplossing in een samenvatting

[Woy]

RoelZ schreef op vrijdag 11 september 2020 @ 15:28:
Ik moet ook even gaan nadenken hoe ik hier nu het beste antwoord uit selecteer. @Woy , misschien ideeën?

Kies gewoon de eerste post die je geholpen heeft de juiste richting te zoeken. Bijvoorbeeld een van de posts van @mrdemc .

Fijn dat je het opgelost hebt en de oplossing voor jou ook even uit de doeken doet.

[DJMaze]

RoelZ schreef op vrijdag 11 september 2020 @ 15:28:
middels JavaScript XMLHttpRequest (xhr) !

Aha! Gebruik window.fetch() met de juiste CORS. Werkt beter dan de oude XHR.
Moet je wel weten hoe Promises werken

[ Voor 11% gewijzigd door DJMaze op 12-09-2020 10:29 ]

[xh3adshotx]

RoelZ schreef op vrijdag 11 september 2020 @ 20:28:
Alright, mijn initiele vraag is verholpen! (een groot feest!)
Ik heb eindelijk de CORS issue aan de kant van mijn productie omgeving opgelost en de applicatie die stand-alone gehost staat op een ander domein gerechtigd gekregen om alle data op te halen vanuit productie.

Om een toekomstige Tweaker te helpen in dit probleem probeer ik het hieronder zo duidelijk mogelijk op te sommen aan checks en wat uiteindelijk geleid heeft naar mijn oplossing, alhoewel hier vrijwel niemand tegen aan zal lopen.

Het initiele probleem

[...]


Een error log in de Console van mijn Devtools gaf dus aan dat er een bepaalde policy gehanteerd werd op de server waar gegevens vandaan gehaald moesten worden.
Kortom: Het domein vanwaar de aanvraag kwam werd niet geaccepteerd. (ook wel: cross-domain issue)

Iets wat dan vrijwel altijd geroepen wordt is:

[...]

Maar hiermee zet je (logisch) de deur open voor ieder domein. Dus ook andere die even een localhost richten op jouw server zouden dan potentieel bij je gegevens kunnen.

Nu kun je dit dus vrij eenvoudig de asterix (*) zetten op het domein vanuit waar je het request gaat doen.
Houdt er dan rekening mee dat je eventuele andere domeinen blokkeert, mocht je die ook toegang willen bieden.

Het setten van deze header kun je op verschillende manieren mogelijk maken.

1. In het geval van Apache, in je .htaccess

code:

<IfModule mod_headers.c>
Header add Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Methods "GET, POST, OPTIONS"
Header add Access-Control-Allow-Headers "origin, content-type, x-requested-with"
</IfModule>

2. In het geval van PHP, in het bestand dat wordt aangeroepen wanneer de data wordt opgevraagd.
In mijn geval draai ik de Wordpress REST API en komt hier de functions.php er tussendoor.

PHP:

if (isset($_SERVER['HTTP_ORIGIN'])) {
  $http_origin = $_SERVER['HTTP_ORIGIN'];
    
  if ($http_origin == "http://localhost:8080" || $http_origin == "https://www.mijnanderedomein.com")
  {
    header('Content-Type: application/json');
    header("Access-Control-Allow-Origin: *");
    header('Access-Control-Allow-Methods: GET, POST, OPTIONS'); 
    header('Access-Control-Allow-Headers: Content-Type, X-Requested-With');
  }
}

Normaliter zou dit al de oplossing zijn, ware het niet dat in mijn geval de server (Apache.conf of PHP.ini) zo ingesteld was dat het de OPTIONS request tegen hield en daardoor de Preflight check faalde, waardoor vervolgens mijn Requests alsnog geweigert bleven.

Door onderstaande toe te voegen aan de .htaccess kon ik er zeker van zijn dat een OPTIONS request naar een zelfgeschreven test bestand mij toe zou moeten laten.
Dit staat los van de CORS headers, maar dus puur een OPTIONS request op een bestand.

code:

RewriteCond %{REQUEST_METHOD} !^(GET|OPTIONS|HEAD|POST) [NC]
RewriteRule .* - [F,L]

Dit gaf me voor het eerst een ander result dan voor heen. Namelijk de 405, Method not allowed.
Hiermee werd het duidelijk dat het wel bij de server moest liggen. De hostpartij had dit aangepast in hun configuratie en daarmee kon ik dan eindelijk normaal gebruik maken van API calls vanuit een ander domein.


Graag wil iedereen in deze thread bedanken en met name @Anoniem: 882605 @n9iels @xh3adshotx @Woy en @mrdemc

Goed dat je het opgelost hebt! Was dit topic helaas vergeten en heb dus niet meer gereageerd - sorry.

[armageddon_2k1]

Dit las als een IT detective novel. Fijn dat er een oplossing is!