sciencetalk

Ik wil 2 PHP variabelen (in php.ini) van de server waar ik m'n website host, wijzigen. Ik kan niet rechtsstreeks bij die PHP instellingen komen, dus moet ik het via een omweg doen. Nu wilde ik dat doen m.b.v. een .htaccess bestand welke ik in de root van m'n website heb geplaatst. Dit is de inhoud van m'n .htaccess bestand:
Je raadt het al: dit werkt niet. Maar waarom werkt dit niet? En hoe geef ik die PHP variabelen dan wel de juiste waarden?

Zou normaal wel moeten werken maar ik vermoed dat je webhost niet wil dat je deze aanpast.

Niet elke host laat überhaupt .htaccess toe. Je zou ook ini_set() kunnen gebruiken, gewoon direct in je PHP bestanden.

Niet elke host laat überhaupt .htaccess toe. Je zou ook ini_set() kunnen gebruiken, gewoon direct in je PHP bestanden.

Ja die tip ben ik zojuist ook op een site tegengekomen. Alleen nog ff uitzoeken in welke bestanden en op welke lokatie in de bestanden ik die opdrachten moet plaatsen.

Het beste daar waar je het in een functie nodig hebt. Om maar eens een voorbeeld te noemen: in een automatische mail die ik een programma laat sturen op het moment dat een gebruiker een opmerking ergens bij wil plaatsen, pas ik ini_set toe voor de SMTP-instellingen. Alleen op het moment dat die functie wordt aangeroepen wordt de ini_set toegepast, anders gelden de standaard SMTP instellingen.

Helaas is het niet mogelijk om magic_quotes_gpc of register_globals aan of uit te zetten met ini_set(). Dit komt, omdat magic quotes en register globals al worden gedaan voordat je code überhaupt wordt aangeroepen. Zie ook de PHP handleiding: http://nl2.php.net/manual/en/security.magi...s.disabling.php

De twee regels die je noemde in de .htaccess zouden moeten werken, werkt dit niet dan is het inderdaad waarschijnlijk dat de server het niet toestaat. Even los tussendoor: weet je zeker dat register_globals aanstaat op de server? Bijna geen enkele server doet dat meer. Je kan het testen door een PHP bestandje aan te maken en de functie phpinfo() aan te roepen. Dat geeft een lange lijst met alle instellen die op de server gelden.

De manier waarop ik het probleem met magic_quotes oplos is door hierop te testen met de get_magic_quotes_gpc() functie en dan te beslissen of ik handmatig quotes toevoeg of niet.

Eerlijkgezegd vind ik dat een beetje omslachtig, iets als magic_quotes_gpc zou ieder fatsoenlijk hostingbedrijf moeten aanzetten of tenmiste moeten toestaan middels htaccess of een andere manier van instellen.

Register globals is misschien een ander verhaal gezien het aanzetten daarvan juist veiligheidsgevolgen heeft, maar het standaard uitschakelen daarvan geef tot de dag van vandaag ellende met oude scripts. Wat dat betreft had men beter kunnen kiezen voor een soort deport_request_variables() waarmee je ze voor nieuwe scripts zou kunnen verwijderen.

Eerlijkgezegd vind ik dat een beetje omslachtig, iets als magic_quotes_gpc zou ieder fatsoenlijk hostingbedrijf moeten aanzetten of tenmiste moeten toestaan middels htaccess of een andere manier van instellen.

Of net niet? magic_quotes is niet helemaal waterproof om bv mysql injection te voorkomen. Je moet sowieso zelf nog eens mysql_real_escape_string() toepassen. Maar als magic_quotes dus reeds aanstaat moet je eerst weer stripslashes() doen omdat die magic_quotes dus wat extra heeft gedaan waar je helemaal niet om vroeg.

In PHP 6.0 is magic_quotes dan ook weggelaten.

Dat is inderdaad ook weer zoiets wazigs.. magic_quotes_gpc heeft een hele tijd standaard aan gestaan - en bij versie 6 is het opeens weg. Eigenlijk zou het dan handiger zijn om gpc vanaf dan te escapen volgens het mysql recept... alleen wil men mysql laten escapen ipv het in php zelf te doen, wat voorlopig onzinnig is omdat mysql toch altijd dezelfde karakters escaped.

Die wispelturigheid vind ik echt een nadeel van php, zonder bijzondere voorzorgen werken zaken verschillend op verschillende versies, zelfs als die gewoon hun default configuratie hebben. Het werkt ook nogal vertragend op de uitrol van nieuwe versies, als je als hostingtoko een major upgrade uitvoert weet je bijna zeker dat er voor de helft van je klanten op dat moment iets breekt - leuk voor de supportafdeling

PHP is dan ook maar een brak taaltje bij momenten. Weinig structuur enzo, slecht in het opmerken van foute code (bv verwijzen naar onbestaande variabelen enzo), en ik kan zo nog wel even doorgaan.