Tijden veranderen
$_SERVER
Ad Fundum op 22/01/2021 21:18:27:
Dat iets kan zijn een eigen HTTP-header in $_SERVER['HTTP_<eigen_header>']
Hoe kan ik een eigen_header
Zelf maken
doorsturen
opvragen
Jan
Code (php)
1
2
3
4
5
2
3
4
5
$.ajax({
url: '/foo/bar.php',
headers: {'x-my-header': 'my-csrf-token'},
...
});
url: '/foo/bar.php',
headers: {'x-my-header': 'my-csrf-token'},
...
});
In je $_SERVER komt die dan terug als $_SERVER['HTTP_X_MY_HEADER'].
Code (php)
1
2
3
4
5
2
3
4
5
var xhr = new XMLHttpRequest();
xhr.open('GET', <url>, true); // true voor async
xhr.responseType = 'text'; // stelt headers in
xhr.setRequestHeader('X-Requested-With', 'XMLHttpRequest'); // eigen header
xhr.send();
xhr.open('GET', <url>, true); // true voor async
xhr.responseType = 'text'; // stelt headers in
xhr.setRequestHeader('X-Requested-With', 'XMLHttpRequest'); // eigen header
xhr.send();
In PHP kun je de eigen header zo uitlezen:
Wanneer je dit gebruikt voor het verhogen van de veiligheid, stuur je een CSRF-token mee. Door het XHR-verzoek via HTTP POST te doen, voorkom je dat de data in logs van webservers komt:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
let formData = new FormData();
formData.append('CSRF', <eigen_token_hier>);
xhr.open('POST', <url>, true); // true voor async
xhr.responseType = 'text'; // stelt headers in
xhr.setRequestHeader('X-Requested-With', 'XMLHttpRequest'); // eigen header
xhr.send(formData);
formData.append('CSRF', <eigen_token_hier>);
xhr.open('POST', <url>, true); // true voor async
xhr.responseType = 'text'; // stelt headers in
xhr.setRequestHeader('X-Requested-With', 'XMLHttpRequest'); // eigen header
xhr.send(formData);
In PHP ontvang je het CSRF-token alsof een formulier was gepost, dus in $_POST['CSRF'], maar ook in $_REQUEST['CSRF']. Omdat je bij $_POST zeker weet dat het via HTTP POST ging, en niet via HTTP GET of cookies, kan je beter $_POST aanhouden.
Code (php)
1
header('X-DoSomething: Hello');
Die X ervoor is een ongeschreven regel die aangeeft dat het geen standaard-header is.
Gewijzigd op 24/01/2021 18:20:34 door - Ariën -
- Ariën - op 24/01/2021 18:19:42:
Die X ervoor is een ongeschreven regel die aangeeft dat het geen standaard-header is.
Die X is al bijna 9 jaar deprecated. ;-) Uit de samenvatting van RFC 6648:
Quote:
Historically, designers and implementers of application protocols
have often distinguished between standardized and unstandardized
parameters by prefixing the names of unstandardized parameters with
the string "X-" or similar constructs. In practice, that convention
causes more problems than it solves. Therefore, this document
deprecates the convention for newly defined parameters with textual
(as opposed to numerical) names in application protocols.
have often distinguished between standardized and unstandardized
parameters by prefixing the names of unstandardized parameters with
the string "X-" or similar constructs. In practice, that convention
causes more problems than it solves. Therefore, this document
deprecates the convention for newly defined parameters with textual
(as opposed to numerical) names in application protocols.
Het officiële advies is dan ook om geen headers meer te gebruiken die beginnen met 'X-'.
Een van de gedachtes hierachter is dat niet-standaard headers na verloop van tijd standaard kunnen worden, en dat dan de ellende pas goed begint. Eigenlijk zou je dan namelijk die X-prefix moeten laten vervallen, maar dat gaat problemen geven met bestaande software die van die X-header gebruik maakt. Het alternatief is om de header mét de X-prefix de standaard te maken, maar dan kun je op basis van de X-prefix niet meer bepalen of je te maken hebt met een standaard of niet-standaard header.
Voorbeeld: de header X-Frame-Options is in 2009 geïntroduceerd als niet-standaard header. In 2013 is de header tot standaard verheven. Aan de andere kant is de Refresh-header, die al sinds 1995 bestaat, nooit als standaard aangenomen. Op basis van de naamgeving kun je dus niet bepalen of een header al dan niet standaard is. Het toevoegen van een indicatie dat een header niet standaard is, is dan ook niet zinvol en daarom moet je het niet doen, zo is de gedachte achter de RFC.
Als je het netjes wilt doen, gebruik je gewoon een logische, betekenisvolle naam waarvan je enigszins het vermoeden hebt dat die nog niet officieel in gebruik is.
Gewijzigd op 25/01/2021 02:36:16 door Willem vp
- verzoek-headers van een HTTP client aan PHP, die kan je uitlezen via $_SERVER[HTTP_<mijn_header>];
- antwoord-headers van PHP naar een HTTP client, die kan je versturen via header();
De HTTP client is meestal een browser, maar kan net zo makkelijk een andere HTTP client als een PHP script met de cURL-extentie.
Willem vp op 25/01/2021 02:12:51:
Die X is al bijna 9 jaar deprecated. ;-) Uit de samenvatting van RFC 6648:
Het officiële advies is dan ook om geen headers meer te gebruiken die beginnen met 'X-'.
Etc......
- Ariën - op 24/01/2021 18:19:42:
Die X ervoor is een ongeschreven regel die aangeeft dat het geen standaard-header is.
Die X is al bijna 9 jaar deprecated. ;-) Uit de samenvatting van RFC 6648:
Quote:
Historically, designers and implementers of application protocols
have often distinguished between standardized and unstandardized
parameters by prefixing the names of unstandardized parameters with
the string "X-" or similar constructs. In practice, that convention
causes more problems than it solves. Therefore, this document
deprecates the convention for newly defined parameters with textual
(as opposed to numerical) names in application protocols.
have often distinguished between standardized and unstandardized
parameters by prefixing the names of unstandardized parameters with
the string "X-" or similar constructs. In practice, that convention
causes more problems than it solves. Therefore, this document
deprecates the convention for newly defined parameters with textual
(as opposed to numerical) names in application protocols.
Het officiële advies is dan ook om geen headers meer te gebruiken die beginnen met 'X-'.
Etc......
Interessant zeg.
Dan lijkt een prefix met (een afkorting van) je sitenaam een stuk logischer. Dus 'PH-BladieBlah' in dit geval.
Gewijzigd op 25/01/2021 10:53:18 door - Ariën -
- Ariën - op 25/01/2021 10:52:41:
Dan lijkt een prefix met (een afkorting van) je sitenaam een stuk logischer. Dus 'PH-BladieBlah' in dit geval.
Om in lijn te zijn met RFC 4288 zou je dan het voorvoegsel "PRS-" (personal space) kunnen gebruiken, dus "PRS-phphulp.nl-Mijn-Eigen-Header" of zo.
(Overigens gaat RFC 4288 over media types en niet over headers, maar omdat bij media types een soortgelijk probleem speelde is het geen slecht idee om bij headers een soortgelijke oplossing aan te houden; dat wordt ook in appendix B van RFC 6488 genoemd.)
Wat je ook voor voorvoegsel kiest, gebruik het in ieder geval alleen als het extreem onwaarschijnlijk is dat het ooit een standaard header zal gaan worden.
Gewijzigd op 25/01/2021 11:26:44 door Willem vp