[PHP] checken of een file include/required is zoniet >> erro

[WPN]

Ik ben bezig met een site in php.

In deze pagina werk ik met een soort van template....
ik heb dus index.php waarin verschillende files geinclude worden zodat de site
er uit komt te zien zoals het hoort

ik heb dus losse bestanden:
index.php
menu.php
header.php
$teksten.php

$teksten.php zijn dus verschillende bestanden met de content van de site....

deze bestanden include ik dus, maar die zijn ook benaderbaar als je zelf de volledige URL intikt....

Ik wil dit afvangen wanneer de file, die eigenlijk include hoort te worden, direct opgevraagt wordt met een melding als iets van: Deze file is niet direct oproepbaar (of iets in die trent, of direct door verwijzen naar de index.php)


Ik heb op dit moment een oplossing met een sessie
MAAR:
als de index pagina geladen is, is de sessie variabelle gezet, en als je dan die file direct benaderd dan kom je er dus alsnog op...

is er uberhaupt een manier om dit af te vangen?


(als ik het duidelijker kan omschrijven dan edit ik mn posting wel)

php: 5.0
windows 2000
iis: 5.0

[André]

Zet in de losse pagina's:

JavaScript:

if (top.location.href != "http://www.domein.nl/index.php") { window.open("index.php"); }

Bij nader inzien in NMe84's oplossing ook afdoende

[ Voor 39% gewijzigd door André op 06-11-2004 00:46 ]

[NMe]

Zet gewoon bovenaan de pagina die je template parset een variabele:

PHP:

$in_site = true;

En check dan op de geïnclude pagina's dit:

PHP:

if (!isset($in_site) || ($in_site !== true))
  die('FOUT!');

[ Voor 6% gewijzigd door NMe op 06-11-2004 00:39 ]

[WPN]

@andre javascript is geen optie, omdat ik de content include van de file

@NMe84 damn it!! dat werkt dus ik zat gewoon moeilijk te doen met sessies


thnx

[Verwijderd]

Mooier is het om de werbserver zo te configureren dat hij het niet pikt als je die bestanden direct wilt opvragen. Zo kun je bijvoorbeeld alle te includen bestanden in een directory zetten die je afschermt met een .htaccess bestand.

Veel mooier dan in je code moeilijk gaan zitten doen.

[ Voor 3% gewijzigd door Verwijderd op 06-11-2004 01:07 ]

[Tofu]

NMe84 schreef op 06 november 2004 @ 00:38:
Zet gewoon bovenaan de pagina die je template parset een variabele:

PHP:

$in_site = true;

En check dan op de geïnclude pagina's dit:

PHP:

if (!isset($in_site) || ($in_site !== true))
  die('FOUT!');

Dan kan je toch gewoon de pagina openen via bestand.php?in_site=true
En dan heb je niks meer aan de beveiliging?
Niet bij alle servers werkt dit, maar bij mij voorbeeld wel ..

[Verwijderd]

tofu schreef op 06 november 2004 @ 01:12:

Dan kan je toch gewoon de pagina openen via bestand.php?in_site=true
En dan heb je niks meer aan de beveiliging?
Niet bij alle servers werkt dit, maar bij mij voorbeeld wel ..

Het lijkt mij zeer sterk dat jij een boolean parameter kunt meegeven in een GET request. Die bevat namelijk alleen string values.

[Tofu]

Verwijderd schreef op 06 november 2004 @ 01:14:
[...]

Het lijkt mij zeer sterk dat jij een boolean parameter kunt meegeven in een GET request. Die bevat namelijk alleen string values.

Ik vond het ook gek, maar ik kwam tot die conclussie,
een voorbeeldje; http://www.saai.be/?p=g&i=8
En in mijn code is de eerste plek waar $i voorkomt van den eerste keer dit;

$title = "SELECT * FROM `games` WHERE id = '$i' LIMIT 0 , 1";

Moet dus niks opvragen uit de url, doet ie vanzelf gek maar handig

Staan zo nog rare dingen ingesteld bij mn host, ik zie voorbeeld nooooit errors.
Er handig om te debuggen als je niet ziet welke lijn fout is.
En ik zelf kan het niet wijzigen.

[ Voor 17% gewijzigd door Tofu op 06-11-2004 01:22 ]

[MBV]

En hoe parst PHP een string met de waarde "True"? Juist, als boolean true Dat is nou de kracht van php

En aan tofu: ik zou dan maar heel snel php opnieuw instellen als je in een productieomgeving draait. Is een veelgemaakte fout om die setting (hoe-heet-hij-ook-al-weer) op true te laten staan.
GET- en POST-variabelen is maar 1 goeie manier voor om op te vragen: met $_GET['naam'] of $_POST['naam']

[Tofu]

MBV schreef op 06 november 2004 @ 01:21:
En hoe parst PHP een string met de waarde "True"? Juist, als boolean true Dat is nou de kracht van php

Mja, daar heb je een punt ..

En aan tofu: ik zou dan maar heel snel php opnieuw instellen als je in een productieomgeving draait. Is een veelgemaakte fout om die setting (hoe-heet-hij-ook-al-weer) op true te laten staan.
GET- en POST-variabelen is maar 1 goeie manier voor om op te vragen: met $_GET['naam'] of $_POST['naam']

Ik heb daar zelf niks aan in te stellen, ik zie het foute er niet direct van in eigenlijk?

[NMe]

MBV schreef op 06 november 2004 @ 01:21:
En hoe parst PHP een string met de waarde "True"? Juist, als boolean true Dat is nou de kracht van php

Als je goed kijkt zie je dat ik vergelijk met de negatieve identiteitsoperator (!==), en die kijkt dus ook of het type overeen komt. En dit mag dan wel goed gaan:

PHP:

if ('true' == true)
  echo 'blaat';

Dat betekent niet dat dit werkt:

PHP:

if ('true' === true)
  echo 'blaat';

Verder werkt de eerste niet omdat 'true' naar de boolean waarde true wordt omgezet, maar omdat het geen lege string is, en niet de waarde '0' of 0 bevat. Volgens mij zou dit zelfs werken:

PHP:

if ('false' == true)
  echo 'blaat';

Maar ik ben hier nu ff niet in de gelegenheid om dat te testen.

MBV schreef op 06 november 2004 @ 01:21:
Is een veelgemaakte fout om die setting (hoe-heet-hij-ook-al-weer) op true te laten staan.

Register_globals. En die moet inderdaad uit, dan heb je dit hele probleem niet.

Edit:

tofu schreef op 06 november 2004 @ 01:12:
Dan kan je toch gewoon de pagina openen via bestand.php?in_site=true
En dan heb je niks meer aan de beveiliging?
Niet bij alle servers werkt dit, maar bij mij voorbeeld wel ..

Er weet toch niemand dat die variabele zo heet trouwens? Knappe jongen die daar achter komt.

[ Voor 41% gewijzigd door NMe op 06-11-2004 01:30 ]

[Verwijderd]

MBV schreef op 06 november 2004 @ 01:21:

En hoe parst PHP een string met de waarde "True"? Juist, als boolean true Dat is nou de kracht van php

Ik ben prima op de hoogte van de zwakte van PHP. Er is nog iets van te maken als je de !== operator gebruikt, zoals NMe84 voorstelt. Ik zou zeggen: probeer zelf eens te bedenken of "true" === true

[ Voor 4% gewijzigd door Verwijderd op 06-11-2004 01:25 ]

[dingstje]

Gebruik een define().

PHP:

define('IN_SITE', true);

PHP:

if (IN_SITE !== true) {die(); }

Je kunt niks definen dmv de GET/POST variablen.

[Helox-in-a-box]

Verwijderd schreef op 06 november 2004 @ 01:04:
Mooier is het om de werbserver zo te configureren dat hij het niet pikt als je die bestanden direct wilt opvragen. Zo kun je bijvoorbeeld alle te includen bestanden in een directory zetten die je afschermt met een .htaccess bestand.

Veel mooier dan in je code moeilijk gaan zitten doen.

dit lijkt mij ook de mooiste oplossing, je maakt gewoon een dir aan naast of onder de DocumentRoot, kan je gewoon nooit bij komen met http in dat geval, alleen met ftp en shell toegang ipc

tofu schreef op 06 november 2004 @ 01:12:
[...]


Dan kan je toch gewoon de pagina openen via bestand.php?in_site=true
En dan heb je niks meer aan de beveiliging?
Niet bij alle servers werkt dit, maar bij mij voorbeeld wel ..

Alleen als registerglobals aan staat en sinds versie 4.2.0 staat dat standaard uit bij een default config.

[simon]

dingstje schreef op 06 november 2004 @ 10:46:
Gebruik een define().

PHP:

define('IN_SITE', true);

PHP:

if (IN_SITE !== true) {die(); }

Je kunt niks definen dmv de GET/POST variablen.

Dat zou dus een warning opleveren, want bij die define hou je er niet rekening mee dat wanneer je die var niet definet dat hij dan niet bestaat. Cheatah's oplossing met .htaccess files is de netste

Daarnaast moet imho register_globals uit en als je geen htaccess dingen wil prutsen kun je NMe84's oplossing gebruiken

[Jordi]

Warning opleveren?

[simon]

Jotti schreef op 06 november 2004 @ 11:23:
Warning opleveren?

Dat is dan een nette oplossing
Maar sowieso is die van Cheatah het netst, maar als je je script verspreid is het zoals je nu doet (met defined) netter Want op IIS heeft zo'n .htaccess niet echt veel zin

[gvanh]

Het valt me op dat hier de term "Mod Rewrite" nog niet gevallen is. Dit is een erg gracieuze oplossing voor als je op Apache werkt. Het geeft je de mogelijkheid om nog VOOR een url door PHP wordt bekeken, deze door Apache te laten veranderen. Zo zou je alle verwijzigingen naar betanden die NIET index.php zijn, kunnen laten door verwijzen naar index.php. In index.php kun je dan bekijken of de opgevraagde pagina geldig is ja of nee. Afhankelijk daarvan kun je dan actie ondernemen.

Uiteraard moet de server waarop je de website neerzet wel deze Rewrite Rules (die terecht komen in een .htaccess bestand.) ondersteunen.

Kijk voor meer info ook op http://httpd.apache.org/docs-2.0/mod/mod_rewrite.html.

"Despite the tons of examples and docs, mod_rewrite is voodoo. Damned cool voodoo, but still voodoo."

-- Brian Moore

[dingstje]

Mod rewrite is overkill hiervoor. Als je kan werken met .htaccess dan gooi je 't beter allemaal in een aparte map met een Deny From All.

[Verwijderd]

Simon schreef op 06 november 2004 @ 11:02:
[...]


Dat zou dus een warning opleveren, want bij die define hou je er niet rekening mee dat wanneer je die var niet definet dat hij dan niet bestaat. Cheatah's oplossing met .htaccess files is de netste

Daarnaast moet imho register_globals uit en als je geen htaccess dingen wil prutsen kun je NMe84's oplossing gebruiken

Dat kun je ook netjes afvangen:

PHP:

if (!defined('IN_SITE') || IN_SITE !== true) {die(); }

Voordeel hiervan is dat je niet afhankelijk bent van andere settings (.htaccess en register_globals). (Het checken op true is eigenlijk niet eens nodig)

[ Voor 4% gewijzigd door Verwijderd op 06-11-2004 13:00 ]