XML ophalen via SSL met libxml weigert
Om een XML-feed op te halen van een bepaalde site, gebruik ik deze code. Echter, de website is sinds kort overgeschakeld op SSL, en sindsdien krijg ik het script niet meer aan de praat.
Ik krijg vanuit cURL steeds de melding:
Peer's Certificate issuer is not recognized.
Wat moet ik nu doen? Ik heb al gekeken naar CURLOPT_SSL_VERIFYPEER op 0, maar lijkt ook geen soelaas te bieden.
Vreemd genoeg krijg ik dit terug? Terwijl het toch echt een constante is. Dat kent hij blijkbaar hier niet :/
Notice: Use of undefined constant CURLOPT_VERIFYPEER - assumed 'CURLOPT_VERIFYPEER' in
Ik krijg vanuit cURL steeds de melding:
Peer's Certificate issuer is not recognized.
Wat moet ik nu doen? Ik heb al gekeken naar CURLOPT_SSL_VERIFYPEER op 0, maar lijkt ook geen soelaas te bieden.
Vreemd genoeg krijg ik dit terug? Terwijl het toch echt een constante is. Dat kent hij blijkbaar hier niet :/
Notice: Use of undefined constant CURLOPT_VERIFYPEER - assumed 'CURLOPT_VERIFYPEER' in
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<?php
$username = "secret";
$password = "topsecret";
$url = "https://www.site.nl/api/feed.php";
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_USERPWD, $username . ':' . $password);
$result = curl_exec($ch);
$xml = simplexml_load_string($result,NULL, LIBXML_NOCDATA);
if(!$xml) {
echo "<p>Feed is stuk: ".curl_error($ch)."</p>";
} else {
// doe de rest
}
curl_close($ch);
?>
$username = "secret";
$password = "topsecret";
$url = "https://www.site.nl/api/feed.php";
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_USERPWD, $username . ':' . $password);
$result = curl_exec($ch);
$xml = simplexml_load_string($result,NULL, LIBXML_NOCDATA);
if(!$xml) {
echo "<p>Feed is stuk: ".curl_error($ch)."</p>";
} else {
// doe de rest
}
curl_close($ch);
?>
Gewijzigd op 09/05/2017 12:36:48 door - Ariën -
Lama, zie dat je eerst in moet loggen.
Gewijzigd op 09/05/2017 12:33:29 door Veur Heur
Dat inloggen heeft altijd gewerkt. Nadat het boeltje op SSL over ging werkte het script niet meer.
Gewijzigd op 09/05/2017 12:36:09 door - Ariën -
Kun je hier iets mee? http://unitstep.net/blog/2009/05/05/using-curl-in-php-to-access-https-ssltls-protected-sites/
Ja, klopt. Blijkbaar lopen de parameters van cURL zelf niet gelijk met die van PHP. Of ik keek in een gedateerde manual. Maar het is opgelost. :-)
Wel bizar dat ik deze setting nodig heb gezien het certificaat verder prima oogt?
Wel bizar dat ik deze setting nodig heb gezien het certificaat verder prima oogt?
Bij "wget" heb je vaak hetzelfde, daar kun je de check op het certificaat ook beter uitschakelen om fouten te voorkomen.
Of je installeert de ca certificates, dat lost ook een hoop op.
Dat zou ook een goed idee zijn. Eens in verdiepen!
Opolo Webdesign op 09/05/2017 12:49:21:
Bij "wget" heb je vaak hetzelfde, daar kun je de check op het certificaat ook beter uitschakelen om fouten te voorkomen.
Gooi je daarmee niet het kind met het waswater weg?
Min of meer wat @Ben zei. 1 minuut googlen (oud artikel, maar nog steeds relevant, en illustreert waarom je dit niet uit zou moeten zetten).
Gewijzigd op 09/05/2017 15:00:05 door Thomas van den Heuvel
het ligt wel een beetje aan de situatie, Thomas. Maar infeite is een certificaat altijd het beste.
De situatie zijnde wat? Hoeveel tijd je aan een klus mag spenderen? Hoe erg het is wanneer je applicatie niet veilig is? Hoe lui iemand zich op dat moment voelt en maar bochten afsnijdt in plaats van zijn/haar werk fatsoenlijk te doen? Hoe professioneel een programmeur daadwerkelijk is of hoeveel verstand van zaken iemand eigenlijk heeft?
Zijn er voorbeelden waarin certificaten niet werken? En wat is daar dan de oorzaak van?
Als je niet kunt rechtvaardigen om CURLOPT_SSL_VERIFYPEER niet te gebruiken dan zou je dat niet moeten doen.
Dat lijkt mij een stap in de goede richting.
Zijn er voorbeelden waarin certificaten niet werken? En wat is daar dan de oorzaak van?
Als je niet kunt rechtvaardigen om CURLOPT_SSL_VERIFYPEER niet te gebruiken dan zou je dat niet moeten doen.
- Ariën - op 09/05/2017 13:43:21:
Dat zou ook een goed idee zijn. Eens in verdiepen!
Dat lijkt mij een stap in de goede richting.
Het licht eraan wat er over de lijn gaat. In deze situatie zie ik dit even als een quick-fix. Als het gevoelige informatie was had ik het wel ingrijpender aangepakt, maar een paar treintijden uit een API, dat kan geen kwaad als iemand het zou sniffen. Bij een volgende update zal het wel goedkomen.
- Ariën - op 09/05/2017 12:39:38:
Misschien wil je dit antwoord nog wat nuanceren dan, voor het geval andere mensen zoeken naar een oplossing en niet verder kijken dan deze "oplossing".
Daar heb jij al een link over geplaatst met een oplossing. ;-)
Ik ga niet graag zomaar zonder het uitgeprobeerd te hebben beschrijven hoe het wel moet.
Ik ga niet graag zomaar zonder het uitgeprobeerd te hebben beschrijven hoe het wel moet.
Gewijzigd op 09/05/2017 15:59:04 door - Ariën -
- Ariën - op 09/05/2017 15:58:04:
Ik ga niet graag zomaar zonder het uitgeprobeerd te hebben beschrijven hoe het wel moet.
Maar je zou wel kunnen aangeven dat het uitzetten van een identiteitscheck nou niet bepaald verstandig is. Het hele idee van HTTPS / SSL is toch dat je in een veilige omgeving informatie uitwisselt? Een controle of je dat ook daadwerkelijk met de juiste partij doet lijkt mij daar onderdeel van. HOE je dat vervolgens doet is een tweede.
Het gaat hier (wederom) meer over de vorm van het advies die leidt tot een oplossing en niet zozeer over de (of een specifieke) oplossing zelf. Je moet kunnen onderbouwen waarom je de dingen doet die je doet. Heb je in jouw geval niet direct deze controle nodig, soit. Dit blijkt niet uit je oorspronkelijke vraagstelling. Lijkt me wel een kanttekening waard.
Inmiddels ben ik me daar wel van bewust, een zal het asap doorvoeren :)
Gewijzigd op 09/05/2017 18:17:50 door - Ariën -




