403 bij OPTIONS request WFS

Overig
#1

Sinds vanochtend krijgen we een 403 bij OPTIONS requests naar de WFS service. Voorbeeld:

https://geodata.nationaalgeoregister.nl/bag/wfs?request=GetFeature&service=WFS&typeName=bag:pand&outputFormat=json&srsName=EPSG:4326&CQL_FILTER=identificatie='344100000030583%20'

Content-Type: application/json
Accept:/
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:en-US,en;q=0.8,nl;q=0.6
Access-Control-Request-Headers:authorization
Access-Control-Request-Method:GET
Cache-Control:no-cache
Connection:keep-alive
Origin: http://localhost
Host:geodata.nationaalgeoregister.nl
Pragma:no-cache
Referer:http://localhost:4200/client
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36

Deze zou geen 403 moeten geven. Bij het weglaten van de origin header werkt de request wel (dan krijgen we een 200).

#2

Bedankt voor de melding.
We hebben de oorzaak hiervan gevonden, we gaan het oplossen.

Cees

#3

Hallo Wessel,

We hebben uitgebreid onderzoek gedaan naar het probleem.
Vanmorgen hebben we de overstap gemaakt naar een nieuwe versie, die iets strikter is met CORS requests.
Dit is iets wat je browser automatisch doet als het gaat om het gebruik van services van andere ‘origins’. In dit geval dus de BAG WFS service.

Op dat moment stuurt je browser een OPTIONS call met een aantal headers.
Het probleem is niet de ‘Origin’ header. Zodra je die weg haalt, dan wordt het request niet meer gezien als een preflight request zoals dat heet en wordt de OPTIONS call toegestaan.
Dat is ook wat er in de specificaties over CORS staat en preflight staat:
https://www.w3.org/TR/cors/#resource-preflight-requests

cors-flowchart.png976×756 46.8 KB

In het geval dat de origin header mist, dan komt het request meteen uit bij ‘Not CORS’.
Er worden nog 2 CORS headers meegestuurd, 1 daarvan is “Access-Control-Request-Headers:authorization”.
Dit geeft aan dat in het GET request een Authorization header mee gestuurd gaat worden.
Dit wordt niet toegestaan en daardoor krijgt je het antwoord ‘403 invalid cors’.

Er is ook geen reden om dit mee te sturen, in die header staat het token of in het geval van basic authentication een gebruikersnaam en wachtwoord van jullie eigen applicatie, die naar PDOK toegestuurd word. Als PDOK doen we hier niks mee, maar het is ook onveilig om die zomaar toe te sturen. Dat is ook de reden waarom standaard die header niet is toegestaan.

Als je de header “Access-Control-Request-Headers:authorization” weg laat gaat het ook goed.
Mogelijk dat er in de webapplicatie voor ieder uitgaand request een authorization header word toegevoegd, ongeacht waar het request naar toe gaat, dat resulteert dan in het gedrag wat nu is gezien.

Door terug te gaan naar de oude versie hebben we het probleem tijdelijk ‘opgelost’. Gezien het feit dat dit geen probleem is in onze versie gaan we de nieuwe versie weer activeren.

Hartelijke groet,
Cees

#4

Dank voor de snelle reacties! We hebben het probleem inmiddels aan onze kant opgelost.

2 likes