DOMDocument geeft 403 forbidden af op hosting-omgeving

Door Ronald Ronald Buys op 27-07-2016 15:01

2.880 views

Beste Allen,

hopelijk zet ik dit topic in de juiste categorie!

Ik heb een situatie op het hosted platform waar ik werk. Er is een plugin die gebruik maakt van SimpleXML. Deze plugin laat via een externe site een RSS-feed in.

Het probleem is nu dat in de log wordt aangegeven dat het bestand niet toegankelijk is (403 Forbidden), zie hieronder de log:

[Wed Jul 27 14:51:17 2016] [error] [client 2001:981:b962:1:21b4:9eaf:d408:8b94] PHP Warning: DOMDocument::load(http://*naamvanklant*.nl/xml.php): failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden\r, referer: http://*naamvanklant*.nl/
[Wed Jul 27 14:51:17 2016] [error] [client 2001:981:b962:1:21b4:9eaf:d408:8b94] in /var/www/*naamvanklant*/data/www/*naamvanklant*.nl/wp-content/plugins/wordpress-social-stream/inc/dcwp_rss.php on line 27, referer: http://*naamvanklant*.nl/
[Wed Jul 27 14:51:17 2016] [error] [client 2001:981:b962:1:21b4:9eaf:d408:8b94] PHP Warning: DOMDocument::load(): I/O warning : failed to load external entity "http://*naamvanklant*.nl/xml.php" in /var/www/*naamvanklant*/data/www/*naamvanklant*.nl/wp-content/plugins/wordpress-social-stream/inc/dcwp_rss.php on line 27, referer: http://*naamvanklant*.nl/
[Wed Jul 27 14:51:17 2016] [error] [client 2001:981:b962:1:21b4:9eaf:d408:8b94] PHP Fatal error: Call to a member function getElementsByTagName() on a non-object in /var/www/*naamvanklant*/data/www/*naamvanklant*.nl/wp-content/plugins/wordpress-social-stream/inc/dcwp_rss.php on line 32, referer: http://*naamvanklant*.nl/

Het gaat vooral om de regel:

[Wed Jul 27 14:51:17 2016] [error] [client 2001:981:b962:1:21b4:9eaf:d408:8b94] PHP Warning: DOMDocument::load(http://*naamvanklant*.nl/xml.php): failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden\r, referer: http://*naamvanklant*.nl/

De rest is slechts een gevolg van deze regel. Het volgende heb ik uitgeprobeerd:
1. Ik heb met de config van NGINX en Apache gespeeld zodat de headers cross-domain verzoeken toe laat
2. Ik heb in de config van NGINX en Apache neergezet dat cross-domain verzoeken van overal toegelaten mogen worden
3. Ik heb de rechten van alle folders en bestanden op 777 gezet

Ik gebruik PHP-versie 5.3.3 met furl_open aan. Dit is ook uit PHPinfo() uit te lezen. Het werkt beide niet op Apache en niet op NGINX.

Tot nu toe heeft niks geholpen. Hebben jullie een idee waar ik dit goed moet instellen zodat het gaat werken?

Eventuele andere informatie kan ik zo aanleveren.

Bij voorbaat dank.

- Ariën -

27-07-2016 15:08 gewijzigd op 27-07-2016 15:10

Simpel gokje: Die website staat het niet toe (Forbidden = verboden)?
Kan je die externe pagina wel via je browser openen?

Enne, PHP 5.3.3 is inmiddels wel 6 jaar oud, en krijgt geen updates meer. Ik weet dat er hier een aantal veiligheidslekken in zitten!!!!!

Zorg liever dat de boel geupgraded wordt naar PHP 5.6 of PHP 7

R Ronald Ronald Buys

27-07-2016 15:10 gewijzigd op 27-07-2016 15:12

Beste Ariën,

de feed is wel bereikbaar via de browser. Echter niet via de plugin.

Wij zijn ons hiervan bewust. Mits HardenedPHP via CloudLinux ondersteunen wij dit nog.

- Ariën -

27-07-2016 15:13 gewijzigd op 27-07-2016 15:16

Doe eens een file_get_contents() naar die URL vanuit PHP.
Misschien krijg je dan meer informatie te zien over waarom het geweigerd wordt?

Ronald Ronald Buys op 27/07/2016 15:10:08

Wij zijn ons hiervan bewust. Mits HardenedPHP via CloudLinux ondersteunen wij dit nog.

Je gaat natuurlijk ook opeens tegen missende functies aanlopen in diverse scripts. Veel kant-en-klare pakketten verwachten minimaal PHP 5.4. phpMyAdmin zelfs PHP 5.5

R Ronald Ronald Buys

27-07-2016 15:17

Dit is de melding:

Warning: file_get_contents(http://*naamvanklant*.nl/feed/): failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in /var/www/*naamvanklant*/data/www/*naamvanklant*.nl/info.php on line 5

- Ariën -

27-07-2016 15:19

Dan zou ik het bij die webmaster van die externe feed zoeken. Blijkbaar zal die wel een beveiliging zoals een IP-filtering of een accesskey o.i.d. hebben draaien.

R Ronald Ronald Buys

27-07-2016 16:09

Ik heb het bij de webmaster neergelegd.

Daarbij heb ik nog wat .xml-bestanden op andere domeinen op hetzelfde platform geplaatst. Vervolgens een file_get_contents() gedaan en deze haalt die wel goed op.

- Ariën -

27-07-2016 16:11

Mooi zo, hopelijk is het snel opgelost met de partij.

R Ronald Ronald Buys

27-07-2016 16:12

Ik houd je op de hoogte! Bedankt zover voor je meedenken.

[size=xsmall]Toevoeging op 28/07/2016 08:32:10:[/size]

No the plugin doesnt use simple xml. It uses the php load function.

Loading another domain onto your server is not the issue. The problem is your server preventing

http://*naamvanklant*.nl/staatslieden/feed being loaded by the plugin code. Unfortunately there is nothing we can do on the plugin side to correct this since your server is returning a "403 forbidden" error.

Since we cannot solve the problem I suggest you submit a refund request form and we will refund the plugin cost:

http://themeforest.net/refund_requests/new

_____

Het gaat dus om het inladen van een feed doormiddel van een permalink die een 403 afgeeft. Iemand enig idee waar dit te maken mee kan hebben? Wij hebben toegang tot de gehele omgeving gekregen.

Ivo P

28-07-2016 14:34

kennelijk geeft de externe server waarop de xml staat een forbidden-melding af.

Dat zou voor die ene xml kunnen zijn, dat zou voor alle kunnen zijn.
Dat kan geregeld zijn in een .htaccess bestand of andere config file van het domein.
Het kan ook zijn dat de xml door een php-script wordt opgebouwd en dat php die error geeft.

Kennelijk is het wel via een browser mogelijk om de xml op te halen.

Wat is verschillend?
a) het ipadres
b) het land waar het ipadres thuis hoort (zoals: server staat in Bolivia en xml-server vindt dat niet leuk)
c) andere headers

wat betreft c: in je eerste foutmelding wordt iets met "referer" genoemd.

Je zou eens met curl functies van php kunnen kijken of je daar wel toegang mee krijgt, en of je daarbij de headers zoals jouw browser die stuurt, na kunt bouwen.
Zie bijvoorbeeld met Firebug wat je browser precies stuurt aan de server

- Ariën -

28-07-2016 14:39 gewijzigd op 28-07-2016 14:40

En bovendien lijkt die externe partij toch echt verantwoordelijk om die feed te fixxen of uitleg te geven hoe deze feed een nette '200 OK' resonse teruggeeft, na een request. Dat verwachten de meeste API's en functies.

Reageren

Inloggen om te reageren