Onderwerp: allow_url_fopen = Off

allow_url_fopen = Off

Dit kun je in php.ini best op off zetten.
Maar is er een mogelijkheid dan om voor bepaalde sites dit wel toe te staan?
Want wij werken met een API via file_get_contents...
En die werkt nu niet...
Of is er een andere manier om dit op te lossen die wel werkt? (Andere php functie, fsoc, ...)

Momenteel werkt de API als volgt:
lid logt in op site x
site x roept de inhoud op van onze site met een get: ?login=naam&pass=pass
Onze site output dan een 1 als de gegevens goed zijn en site x weet dan dat de gebruiker mag inloggen.

Kan dit herschreven worden dat het wel werkt?

php_admin_value, misschien kom je daar wat verder mee?

of door in je .htaccess van je site het volgende te zetten:
php_flag allow_url_fopen Off

of

php_value allow_url_fopen 0

Oorspronkelijk geplaatst door WebXtrA-Rámon

of door in je .htaccess van je site het volgende te zetten:
php_flag allow_url_fopen Off

of

php_value allow_url_fopen 0

Helaas, dat werkt niet.

allow_url_fopen is: "PHP_INI_SYSTEM" (Entry can be set in php.ini or httpd.conf)

Zie: http://nl3.php.net/manual/en/ini.php#ini.list

Oorspronkelijk geplaatst door Wido

Helaas, dat werkt niet.

allow_url_fopen is: "PHP_INI_SYSTEM" (Entry can be set in php.ini or httpd.conf)

Zie: http://nl3.php.net/manual/en/ini.php#ini.list

Klopt, ben niet bij de les ;-)

Maar uiteindelijk hebben bijna 80% van onze sites deze API nodig.
Ik kan moeilijk voor elk apart die instellingen aanpassen hé...

Is er geen manier om die API veilig te maken op een andere manier?

php_admin_value geeft trouwens:
"Server fout!

De server kreeg een interne fout en kon uw vraag niet beantwoorden. De server is overbelast of er was een fout in een CGI script.

Indien u van oordeel bent dat deze server in fout is, gelieve de webmaster te contacteren. "

Om het veiliger te maken is er een patch beschikbaar op: http://www.hardened-php.net/

Hiermee kan je instellen dat include(<url>) niet mag, maar fopen()/file_get_contents() wel.

Oorspronkelijk geplaatst door klasje.be

Maar uiteindelijk hebben bijna 80% van onze sites deze API nodig.
Ik kan moeilijk voor elk apart die instellingen aanpassen hé...

Is er geen manier om die API veilig te maken op een andere manier?

php_admin_value geeft trouwens:
"Server fout!

De server kreeg een interne fout en kon uw vraag niet beantwoorden. De server is overbelast of er was een fout in een CGI script.

Indien u van oordeel bent dat deze server in fout is, gelieve de webmaster te contacteren. "

Heb je dat in je virtualhost staan? want zoals hierboven vermeld hoord het niet te werken als je het in je .htaccess zet

Ik heb vanalles geprobeerd.

Voornamelijk dit voorbeeld gevolgd:
http://bugs.php.net/bug.php?id=33723

Maar dan nog is het moeilijk & onveilig omdat per domein te gaan regelen hé...

Echt geen alternatieve methode mogelijk voor die API ofzo?

Oorspronkelijk geplaatst door klasje.be

allow_url_fopen = Off

Dit kun je in php.ini best op off zetten.
Maar is er een mogelijkheid dan om voor bepaalde sites dit wel toe te staan?
Want wij werken met een API via file_get_contents...
En die werkt nu niet...
Of is er een andere manier om dit op te lossen die wel werkt? (Andere php functie, fsoc, ...)

Momenteel werkt de API als volgt:
lid logt in op site x
site x roept de inhoud op van onze site met een get: ?login=naam&pass=pass
Onze site output dan een 1 als de gegevens goed zijn en site x weet dan dat de gebruiker mag inloggen.

Kan dit herschreven worden dat het wel werkt?

Wat jij eigenlijk zoekt is een remote autorisatie service. Laat ik nu toevallig zoiets regelmatig bouwen. Dit werkt als volgt:

1. Gebruiker logt in op site A
2. Site A controleert de logingegevens door het aanroepen van een webservice op Site B.
3. Site B kan op elke gewenste manier de juistheid van de gegevens controleren en dit terug communiceren naar Site A

Dit is een heel effectief systeem dat ik zelf gebruik om belangrijke gegevens transparant door te sluizen naar beter beveiligde servers. Hetzelfde eigenlijk als jullie huidige controle alleen is deze een beetje veiliger en vooral STANDAARD.

Helaas staat dit topic niet ergens bij 'personeel gevraagd', want dan had ik een goede oplossing voor je. Je huidige manier van controleren geeft me echter niet de indruk dat ik je kan helpen door over webservices te gaan praten...

Misschien helpt dit?

include ("http://www.jeserver.nl/login.php?login=naam&pass=pass");

In het login script kun je dan een variabele declareren met 1 of 0 en controleren in het aanroepende proggie. Veder controleer je in een tabelletje of het aanroepende domein dit mag uitvoeren of niet.

RAAR
allow_url_fopen = Off staat in php.ini
Maar toch werkt opeens vandaag die file_get_contents wel...?
Gisteren ging dit niet.
Ik kan me niet herinneren iets veranderd te hebben gisteren avond...

Hoort dit wel zo te gaan nu?

Volgens die rakker van Murphy wel, dacht ik...

Lijkt me zwaar onhandig systeem...

Oorspronkelijk geplaatst door systemdeveloper

include ("http://www.jeserver.nl/login.php?login=naam&pass=pass");

In het login script kun je dan een variabele declareren met 1 of 0 en controleren in het aanroepende proggie. Veder controleer je in een tabelletje of het aanroepende domein dit mag uitvoeren of niet.

Dit gaat no way werken!, als het script al gerunned wordt door de zelfde webserver, kan je netzogoed lokaal checken, en als het al zo is, dan kan je login & pass niet op de $_GET manier declareren. en als het al niet zo is kan je niet een variabele in het lokale script laten declareren met een include alleen!.

Nogal onzin post dus naar mijn mening,

Volgens mij werkt die php.ini setting alleen voor fopen(); file_get_contents haalt de content op van een bepaalde pagina en returned deze, zie niet in wat voor slechts dit kan brengen? Weet trouwens dit laatste niet zeker

@blaaat: ik denk dat je volledig gelijk hebt, uit wat enkele tests uitwijzen.
Via include zou ik dat idd niet zo kunnen oplossen met die get's.
File_get_contents kan dit wel.

file_get_contents zou normaal veilig moeten zijn tenzij men dan de inhoud van die file zou outputten, maar in mijn scripts wordt enkel gekeken of die 1 of 0 is.

Ik zou het graag lokaal kunnen oplossen, maar ik wil niet dat de sites toegang hebben tot de centrale database via het bestand dat geincluded wordt.
Als ze het bestand kunnen includen kunnen ze ook de inhoud lezen en dus wss ook het db wachtwoord...

API moet zeker blijven, want dan kunnen in de toekomst sites die niet bij ons gehost staan ook van deze dienst gebruik maken.
Dat is het grote voordeel van API.

"Veder controleer je in een tabelletje of het aanroepende domein deze API mag uitvoeren of niet."
=> Welke functie is dit weer? (anders google ik wel ff als ik het antwoord niet heb tegen morgen, ik vind het toch wel. ;-) )

Verder nog 1 klein vraagje:
Als de leden registreren wordt er via de API een MD5 wachtwoordje en email adres gegeven door de API, deze worden dan verwerkt op de site en in de db gezet(explode). Zo moet de centrale db niet de bijkomende user gegevens dragen. Maar is er een manier waarop ik kan voorkomen dat een 'slechte' site gewoon alle login's, wachtwoorden en emails opslaat uit deze API?
Want dit wordt geoutputted en aangezien hun site dit nodig heeft, kan de webmaster er dan ook aan hé...

Oorspronkelijk geplaatst door blaaat

Dit gaat no way werken!, als het script al gerunned wordt door de zelfde webserver, kan je netzogoed lokaal checken, en als het al zo is, dan kan je login & pass niet op de $_GET manier declareren. en als het al niet zo is kan je niet een variabele in het lokale script laten declareren met een include alleen!.

Nogal onzin post dus naar mijn mening,

Hehe, je begrijpt het niet helemaal bedoel je? Dan zal ik het je uitleggen:

Als het script op dezelfde server staat, kan het altijd nog onder een ander domein hangen, maar dat terzijde. Als ik 'jeserver.nl' type, hoef je niet direct aan te nemen dat ik DE enige server bedoel. TS weet vast wel dat hiermee de server waarop het script nu draait, wordt bedoeld. Aangezien in de include() een http://-referentie staat naar een URI, zal apache dit netjes parsen volgende http 1.1 regels. Je kunt die paramaters dus netjes uitlezen.

Je hebt 100% gelijk dat je er met een include alléén niet bent... en ik mag hopen dat een autorisatiescriptje ook meer doet dan alleen een variabele zetten.

Nogmaals: TS vroeg een herschrijving van zijn huidige manier van autoriseren en in eerste instantie niet om een betere manier. (Mijn reactie begon trouwens met een betere manier, maar daar heb je zeker overheen gelezen...)

Dus... eerst lezen, dan oefenen, dan vragen, dan blaten graag...

Mvg.

John