[php] file_get_contents("php://input") werkt niet (meer)...

[Atmoz]

Beste,

Sinds 2013 heb ik een PHP script draaien met daarin (onder andere) onderstaande functie:

code:

$data = trim(file_get_contents("php://input"));

Vanuit een applicatie wordt er een POST gedaan naar dit script om wat data door te sturen.
Dit script is sinds die tijd (2013) niet aangepast. Ook met de applicatie die dit aanroept is niets gebeurt. Toch werkt opeens deze functie niet meer. Er komt gewoon geen data meer binnen. Ook met andere test-tooltjes die een POST doen naar dit script werkt het niet...

Als ik dit script op een andere webserver zet werkt het wel gewoon. Er is dus *iets* gebeurt op/bij de webhost (Interconnect) waardoor dit ineens niet meer werkt. Ik heb al diverse keren contact met hun gehad, maar ze weten niet waar het aan ligt. Ze geven ook geen ondersteuning op PHP scripts. En dat hoeft wat mij betreft ook niet, want het script is goed. Er moet alleen een PHP omgeving worden geleverd die goed werkt

Ik vraag me af waar dit aan kan liggen? Wat kan er op de webhost zijn gewijzigd waardoor deze (mijns inziens standaard) functie niet meer werkt? En nog belangrijker: hoe kan dit weer worden "rechtgezet"?

Thanks voor 't meedenken

[Harrie_]

Op de webhost kan natuurlijk van alles gewijzigd zijn. Als het script uit 2013 komt dan is het script nog uit de tijd van < 5.6. Dus ik denk dat het probleem daar wellicht kan liggen?
• Is er bij Interconnect een (major/minor)versie wijziging geweest van PHP?
• Krijg je foutmeldingen te zien? Misschien iets deprecated? Heb je error reporting aan staan om dit te controleren?
• Zit er iets van ini_set in je script waar het aan zou kunnen liggen?
• Heb je in phpinfo() gecheckt of hier een instelling aan of uit staat wat hiermee te maken kan hebben?
• Je geeft aan toegang te hebben tot een andere webhost, heb je gekeken wat de verschillen zijn als je phpinfo() draait? Kun je evt. omgevingsvariabelen met ini_set() geforceerd aan of uit zetten in je script bij Interconnect?

[Barryvdh]

Welke PHP versie? In versies < 5.6 kan je de input stream maar 1 keer uitlezen. Zie http://php.net/manual/en/wrappers.php.php#wrappers.php.input

Dus als je ergens anders in je script dat ook aanroept, gaat het op de 2de plek mis.

[Atmoz]

Harrie_ schreef op dinsdag 10 april 2018 @ 09:20:
Op de webhost kan natuurlijk van alles gewijzigd zijn. Als het script uit 2013 komt dan is het script nog uit de tijd van < 5.6. Dus ik denk dat het probleem daar wellicht kan liggen?

De PHP versie is inderdaad lager dan 5.6 maar er zijn daar geen wijzigingen geweest geven ze aan. Dus met die versie heeft 't altijd prima gewerkt!

• Is er bij Interconnect een (major/minor)versie wijziging geweest van PHP?

Nee.

• Krijg je foutmeldingen te zien? Misschien iets deprecated? Heb je error reporting aan staan om dit te controleren?

Nee heb ik niet. Maar ik "zie" die foutmeldingen ook niet omdat ik dat script niet in een browser aanroep...

• Zit er iets van ini_set in je script waar het aan zou kunnen liggen?

Nee.

• Heb je in phpinfo() gecheckt of hier een instelling aan of uit staat wat hiermee te maken kan hebben?
• Je geeft aan toegang te hebben tot een andere webhost, heb je gekeken wat de verschillen zijn als je phpinfo() draait? Kun je evt. omgevingsvariabelen met ini_set() geforceerd aan of uit zetten in je script bij Interconnect?

Thanks! Dat zijn nog ideeën die ik nog kan doen inderdaad

Barryvdh schreef op dinsdag 10 april 2018 @ 09:21:
Welke PHP versie? In versies < 5.6 kan je de input stream maar 1 keer uitlezen. Zie http://php.net/manual/en/wrappers.php.php#wrappers.php.input

Dus als je ergens anders in je script dat ook aanroept, gaat het op de 2de plek mis.

Het is PHP versie 5.2.10
Ik gebruik die functie maar één keer in het script.

Voor de volledigheid hierbij het hele script:

code:

<?php

  $data = trim(file_get_contents("php://input"));

  $ww = $_GET['ww'];
  
  if ($ww == "test123"){ 

    $naam = $_GET["naam"];
    $bestandje = "./XML/" . $naam .".xml";
    $fp = fopen($bestandje , "w");
    fputs($fp , $data);
    fclose($fp); 

    if (file_exists($bestandje)){
      echo "XML_OK";
    }
  }

?>

[ Voor 9% gewijzigd door Atmoz op 10-04-2018 09:53 ]

[Hopscotch]

Als ik me neit vergis moet de waarde van allow_url_fopen in je ini file op true staan, ik denk zomaar dat dat niet goed staat.

[Atmoz]

Hopscotch schreef op dinsdag 10 april 2018 @ 10:04:
Als ik me neit vergis moet de waarde van allow_url_fopen in je ini file op true staan, ik denk zomaar dat dat niet goed staat.

Thanks, maar staan beide op "ON"

[DJMaze]

Atmoz schreef op dinsdag 10 april 2018 @ 09:48:
De PHP versie is inderdaad lager dan 5.6

Atmoz schreef op dinsdag 10 april 2018 @ 10:08:
Thanks, maar staan beide op "ON"

Wordt het dan geen tijd om eens rap die server te updaten en te beveiligen?

[Atmoz]

DJMaze schreef op dinsdag 10 april 2018 @ 10:25:
[...]


[...]

Wordt het dan geen tijd om eens rap die server te updaten en te beveiligen?

Ik heb geen idee?!
Blijkbaar wel dus.... Met welke reden als ik vragen mag? Wat kan er gebeuren nu?

[Voutloos]

https://secure.php.net/eol.php
PHP 5.2 is al meer dan 7 jaar end-of-life, en krijgt geen security fixes meer, zelfs niet voor de meeste spectaculaire problemen ooit.

Daarnaast bevatten met name 5.3, 7.0 en 7.1 verbeteringen die het leven van je developers heel wat prettiger maken. Bovendien mag je gemiddeld bij de stap van 5.2 naar 7.0 een factor 4 minder CPU usage verwachten, wat voor je responsetijden en load ook niet bepaald een klein effect oplevert.

Atmoz schreef op dinsdag 10 april 2018 @ 10:29:
Wat kan er gebeuren nu?

Van alles, maar je hebt blijkbaar al het geluk van de wereld. De hierboven beschreven voordelen, onderhoud, security fixes, features, performance zouden al genoeg reden moeten zijn. In een minder genuanceerde bui zou ik zelfs kunnen zeggen dat als iemand nu nóg op 5.2 of 5.3 zit, de wereld misschien maar beter af is als zijn server plat gaat.

[ Voor 34% gewijzigd door Voutloos op 10-04-2018 10:53 ]

[Atmoz]

Voutloos schreef op dinsdag 10 april 2018 @ 10:48:
https://secure.php.net/eol.php
PHP 5.2 is al meer dan 7 jaar end-of-life, en krijgt geen security fixes meer, zelfs niet voor de meeste spectaculaire problemen ooit.

Daarnaast bevatten met name 5.3, 7.0 en 7.1 verbeteringen die het leven van je developers heel wat prettiger maken. Bovendien mag je gemiddeld bij de stap van 5.2 naar 7.0 een factor 4 minder CPU usage verwachten, wat voor je responsetijden en load ook niet bepaald een klein effect oplevert.


[...]
Van alles, maar je hebt blijkbaar al het geluk van de wereld. De hierboven beschreven voordelen, onderhoud, security fixes, features, performance zouden al genoeg reden moeten zijn. In een minder genuanceerde bui zou ik zelfs kunnen zeggen dat als iemand nu nóg op 5.2 of 5.3 zit, de wereld misschien maar beter af is als zijn server plat gaat.

Ok thanks.
Dus zeker verstandig om te updaten
Hopelijk valt er dan niets anders om.... Of valt dat wel mee i.v.m. upwards-compatibiliteit?

[mcDavid]

Atmoz schreef op dinsdag 10 april 2018 @ 10:55:
[...]


Ok thanks.
Dus zeker verstandig om te updaten
Hopelijk valt er dan niets anders om.... Of valt dat wel mee i.v.m. upwards-compatibiliteit?

Als dit het enige stukje PHP is wat je draait zou je je in principe weinig zorgen hoeven maken (even los van het in dit topic besproken probleem wat waarschijnlijk dus aan iets anders ligt). Dat zou ook verklaren waarom je nooit veiligheidsproblemen hebt gehad. Dit is zo weinig code dat de kans dat er een kwetsbare constructie in zit, statistich vrij klein is.

Als je meer code hebt draaien (zoals een CMS of iets dergelijks) loont het misschien de moeite om het eerst lokaal even te testen. Updaten naar 5.6 zou in principe weinig problemen op moeten leveren en is ook minimaal nodig om een veilig systeem te hebben. Maar voor de performance kun je het beste gelijk naar 7.* gaan, dat maakt echt een gigantisch verschil.

Ok terug on-topic over je vraag:
Je zult echt op zoek moeten naar foutmeldingen. Het kan bijna niet dat je die niet krijgt. Kijk of je hosting een error log beschikbaar heeft of gooi desnoods display_errors aan.
Als je dan nog niets wijzer wordt, misschien op een paar plekken een var_dump() toevoegen om te kijken wat er in je variablen zit. En of dat klopt met wat je verwacht.

[DJMaze]

Atmoz schreef op dinsdag 10 april 2018 @ 10:29:
Ik heb geen idee?!
Blijkbaar wel dus.... Met welke reden als ik vragen mag? Wat kan er gebeuren nu?

Atmoz schreef op dinsdag 10 april 2018 @ 10:55:
Hopelijk valt er dan niets anders om.... Of valt dat wel mee i.v.m. upwards-compatibiliteit?

Als ik het zo lees is je dagelijks werk niet code schrijven in PHP.

Je kan één van deze vier dingen doen:

1. PHP leren en leren hoe je een WAMP/LAMP stack op je PC draait
2. Een PHP guru vinden die je scripts wil repareren
3. Iemand vinden die de handel van je overneemt
4. De server uit zetten en er een punt achter zetten

[ Voor 7% gewijzigd door DJMaze op 10-04-2018 13:25 ]

[Voutloos]

mcDavid schreef op dinsdag 10 april 2018 @ 11:09:
[...]
Als dit het enige stukje PHP is wat je draait zou je je in principe weinig zorgen hoeven maken (even los van het in dit topic besproken probleem wat waarschijnlijk dus aan iets anders ligt). Dat zou ook verklaren waarom je nooit veiligheidsproblemen hebt gehad. Dit is zo weinig code dat de kans dat er een kwetsbare constructie in zit, statistich vrij klein is.

Security problemen hoeven niet enkel in de eigen PHP code te zitten. In zo'n oude versie is statistisch gezien de kans vrij groot dat je iets kan triggeren voordat uberhaupt de eigen code gerund wordt. Bovendien gaat een oude PHP versie ook vaak hand in hand met oude Apache/nginx, andere oude system troep, oude ssl libraries etc etc.

[CH4OS]

Vraag de hoster of ze jouw site kunnen kopieren naar een andere server, wat nieuwere versies heeft van OS en de gebruikte software. Als dat allemaal goed gaat, zou ik zo snel mogelijk migreren naar een nieuwe server. Als de hoster daar geen zin in heeft, zou ik ook kijken naar alternatieve oplossingen, want dan weet de hoster gewoonweg niet wat die aan het doen is en welke risico's dat bedrijf loopt.

Gaat nog leuk worden voor hen, als straks de GDPR in gaat.

[ Voor 13% gewijzigd door CH4OS op 10-04-2018 11:46 ]

[DePruus]

De functie file_get_contents( vraagt om een filenaam. En als die er niet is. Dan geeft het een foutmelding.
Dus bijvoorbeeld: file_get_contents("lijst.txt");
Kijk hier maar even voor de uitleg: http://php.net/manual/en/function.file-get-contents.php
Dat betekent dat je je code moet herschrijven om een filenaam in de aanroep te krijgen of en variabele kan ook.

[mcDavid]

Voutloos schreef op dinsdag 10 april 2018 @ 11:18:
[...]
Security problemen hoeven niet enkel in de eigen PHP code te zitten. In zo'n oude versie is statistisch gezien de kans vrij groot dat je iets kan triggeren voordat uberhaupt de eigen code gerund wordt. Bovendien gaat een oude PHP versie ook vaak hand in hand met oude Apache/nginx, andere oude system troep, oude ssl libraries etc etc.

Klopt. Daarnaarnaast weet je nooit wat er morgen voor exploits gevonden gaan worden, maar wel dat die op een oude versie iig niet gepatched gaan worden. Updaten is dus onverlet belangrijk.

[mcDavid]

DePruus schreef op dinsdag 10 april 2018 @ 11:52:
De functie file_get_contents( vraagt om een filenaam. En als die er niet is. Dan geeft het een foutmelding.
Dus bijvoorbeeld: file_get_contents("lijst.txt");
Kijk hier maar even voor de uitleg: http://php.net/manual/en/function.file-get-contents.php
Dat betekent dat je je code moet herschrijven om een filenaam in de aanroep te krijgen of en variabele kan ook.

uit jouw bron:

Tip

A URL can be used as a filename with this function if the fopen wrappers have been enabled. See fopen() for more details on how to specify the filename. See the Supported Protocols and Wrappers for links to information about what abilities the various wrappers have, notes on their usage, and information on any predefined variables they may provide.

Wel alles lezen he

offtopic:
Whoops, sorry voor de dubbelpost