Security Security Gegex Handler? (Php)

Y a-t-il une raison pour laquelle vous ne voulez pas utiliser Apache Auth? Je pense que ce serait beaucoup moins compliqué. http://httpd.apache.org/docs/2.2/howto/auth.html

Vous pouvez spécifier des règles d'accès dans un hôte virtuel sur une base répertoire par annuaire, vos informations utilisateur peuvent figurer dans un fichier plat ou une base de données.

Juste une idée, mais peut-être que vous n'avez pas besoin de lutter avec mod_rewrite. Si vous voulez tout gérer de PHP de toute façon, pourquoi ne pas ajouter de fichier de préparation dans votre Vhost? XXX

Il sera inclus avant tout script PHP et vous pouvez rediriger si nécessaire.

Vous avez juste besoin d'une simple fonction de vérification. Un utilisateur est autorisé à accéder à une ressource ou non. Donc, tout d'abord la configuration du contexte: xxx pré>

à côté de celui que nous avons ladite fonction de validation qui par défaut doit renvoyer false code> et prend le contexte comme paramètres: p> xxx pré>

la logique est donc simple: p> xxx pré>

qui vous donne déjà naturellement "LOGIN" " >. Amende. Nous modifierons bientôt les paramètres de cette fonction. Voyons voir comment règles code> et $ URI code> se situe les uns aux autres. P>

Chaque règle peut correspondre sur une URI, au moins le chemin em> peut. Sparons la règle: p> xxx pré>

une règle ne correspond pas ou ne correspond pas au $ URI code>. Si elle correspond, le signe em> décide de ce que cela signifie. P>

Donc, il existe deux groupes spécifiés par le signe em> et on peut dire si le $ URI code> correspond ou non. C'est à nouveau une fonction simple, d'abord que la matrice de règles est filtrée par signe, puis par chemin. P>

Considérez une fonction avec trois paramètres d'entrée qui renvoie le sous-ensemble de toutes les règles sous forme de maquillage Avec l'URI: P>

$rules          = rules_load();
$uri            = $_SERVER['QUERY_STRING'];
$userIsLoggedIn = user_is_logged_in();

$match = rules_match($rules, $uri);

$permitted = $userIsLoggedIn ?: !$match('-') && $match('+');

if ($permitted) {
    # can pass
    echo "can pass";
} else {
    # login first
    echo "login first";
}

/**
 */
function rules_match(array $rules, $uri) {
    return function ($sign) use ($rules, $uri) {
        return array_reduce($rules, function ($a, $v) use ($rules, $sign, $uri) {
            $v[0] === $sign && false !== strpos($uri, substr($v, 1)) && $a[] = $v;
            return $a;
        }, array());
    };
}

Je pense qu'il y a une boucle dans votre idée, d'où la boucle de l'application. Comme ceci:

1. L'agent utilisateur demande une ressource héritée dans le sous-domaine.

2. puisque l'UA doit avoir des informations d'identification valides et la ressource héritée ne peut pas vérifier les informations d'identification, UA est redirigé vers le gestionnaire.

3. Handler vérifie les informations d'identification et redirige l'UA Retour à la ressource héritée.

4. aller à 2.

   Le problème est que la ressource demandée ne peut pas faire de distinction entre les demandes de l'UA aux étapes 1 et 3, car la distinction est définie par les informations d'identification de l'UC, que la ressource héritée n'évalue pas.

   Cette contradiction est également apparente d'un autre point de vue. Imaginez une minute que vous résolvez la boucle et que l'UA est redirigée vers la ressource héritée - quelque chose comme http: / /sub1.example.com/foo.php . Pour que le serveur renvoie la ressource, il faudrait signifier que les informations d'identification n'étaient pas évaluées (car elles ne le font pas), et donc que la ressource est effectivement publique.

   Pour contourner cela, vous devez casser l'impasse en modifiant les règles des étapes 2 ou 3:

   • Pour changer l'étape 2, ajoutez une évaluation des informations d'identification à la réponse de la ressource héritée. La réponse précédente suggérant auto_prepend_file () est dirigé dans cette direction, mais uniquement pour les fichiers hérités PHP - Images, HTML, etc. n'a pas de chance.

   • Pour changer l'étape 3, trouvez un moyen de fournir la ressource héritée sans que l'UA demande directement la ressource. Une possibilité est de disposer du gestionnaire d'obtenir la ressource du système de fichiers et de la mettre sur le fil avec listifile () et de la gestion de l'en-tête HTTP.

     Peut-être une combinaison de ceux-ci fera l'affaire pour vous: auto_prepend_file () Pour appliquer la manipulation d'authentification sur legacy php, et listifile () pour le contenu non PHP.