If include

Je zou een ABS_PATH-constant kunnen aanmaken met define()
En als iemand rechtstreeks naar de pagina gaat bestaat die niet, dat check je met defined() en dan de pagina blokkeren met die()

Dit is een van de redenen waarom je includes buiten de webroot moet opslaan: niemand kan van buitenaf bestanden buiten de root opvragen.

Binnen de root kun je toegang tot bepaalde bestanden blokkeren met .htaccess:

<Files reacties.php>
  Order allow, deny
  Deny from all
</Files>

Kijk eens naar $_SERVER['SCRIPT_FILENAME'], $_SERVER['REQUEST_URI'] of $_SERVER['SCRIPT_NAME'].
Daarin kan je vinden hoe de pagina wordt aangeroepen.

@Ward dat zou de gewenste oplossing zijn, maar afhankelijk van je hosting kun (of kon? weet niet of dit tegenwoordig nog voorkomt) je niet altijd dingen buiten je webdir zetten.

Een alternatieve (betere?) oplossing is natuurlijk om de reacties op te slaan in een database.

Om een voorbeeld te geven van wat PHP Maarten beschrijft:

Zet in de pagina's waarin je reacties mag includen:

<?php
define('INCLUDES_ALLOWED', true);
?>

En bovenaan in reacties php:

<?php
if (defined('INCLUDES_ALLOWED') === false) {
    exit;
    // alternatief: een boodschap met die(), want soms kun je je te pletter
    // zoeken waarom geen reacties worden getoond, je zou bijvoorbeeld kunnen gaan voor
    // die('direct access denied');
}
?>

Dan lijm je twee bestanden aan elkaar met één constante, waardoor je een afhankelijkheid met een verhoogde kans op fouten krijgt. Je kunt ook enkel en alleen in de include toegang tot het bestand zelf uitsluiten:

<?php
if (basename(__FILE__) == basename($_SERVER['SCRIPT_FILENAME'])) {
    header('HTTP/1.1 404 Not Found');
    exit; 
}
?>

Vooral bij shared hosting is serverconfiguratie vaak een drama, maar dan kun je op zijn minst de includes in een aparte directory zoals /includes/ zetten (zodat je die kunt beveiligen) of ze een aparte extensie zoals .inc geven (zodat je die kunt beveiligen).

Dan lijm je twee bestanden aan elkaar met één constante, waardoor je een afhankelijkheid met een verhoogde kans op fouten krijgt

Euh, ten minste twee bestanden. Het ene bestand dient als kapstok om andere bestanden te (kunnen/mogen) includen. Trouwens die foutgevoeligheid afhankelijkheid was er waarschijnlijk al, zo worden mogelijk in het kapstok bestand allerlei controles uitgevoerd op privileges van een gebruiker, wordt er een connectie met de database gemaakt et cetera. De introductie van deze constante garandeert juist dat het kapstok bestand éérst wordt geladen en het andere bestand alleen ingevoegd wordt als hier sprake van is, dat lijkt mij een rechtvaardiging voor deze constructie? Daarmee wordt namelijk gegarandeerd dat de gebruiker de juiste privileges heeft, dat er een database connectie is et cetera... als je dat bestand rechtstreeks aanroept is daar (mogelijk) allemaal geen sprake van.

Het geinclude bestand IS al afhankelijk van het bestand waarin deze geinclude wordt tenzij je dingen dubbel doet en als je dat doet dan had het net zo goed een standalone bestand kunnen zijn.

Zie het als een preconditie(-check), wat is daar mis mee?

EDIT Kun je aannemelijk maken dat dit leidt tot een verhoogde kans op fouten?

>> Euh, ten minste twee bestanden.

Vooral dát bedoel ik inderdaad.

>> Zie het als een preconditie(-check), wat is daar mis mee?

Er is niets mis mee hoor, maar ik zou het zelf anders doen om vooral één reden: ik wil niet op (ten minste) twee plaatsen moeten zijn om één ding te regelen.

Ik bedoelde daarmee meer dat je dit principe voor al je includes op eenzelfde manier kunt gebruiken.

Toegegeven, in jouw geval is er geen (harde) afhankelijkheid tussen bestanden.

Aan de andere kant, de controle die je uitvoert is toch een soort van "blacklist" check, met andere woorden, schetst condities waaronder een bestand niet verder verwerkt zou moeten worden. Er is ook iets voor te zeggen om een "whitelist" check te hebben (wanneer mag iets wel uitgevoerd worden).

:)