Utiliser PHP / Apache pour restreindre l'accès aux fichiers statiques (html, css, img, etc.)

Question

Disons que vous avez beaucoup de html, css, js, img etc fichiers dans un répertoire sur votre serveur. Normalement, n'importe quel utilisateur dans internet-terre pourrait accéder à ces fichiers en tapant simplement l'URL complet de la sorte: http://example.com/static-files/sub/index.html

Maintenant, si vous voulez seulement les utilisateurs autorisés à être en mesure de charger ces fichiers? Pour cet exemple, disons que votre utilisateur se connecte d'abord à partir d'une URL comme ceci: http://example.com/login.php

Comment voulez-vous permettre à l'utilisateur connecté à la vue de la index.html fichier (ou les fichiers sous "statique-files"), mais limiter le fichier à tout le monde?

Je suis venu avec deux solutions possibles à ce jour:

Solution 1
Créer les suivants .fichier htaccess sous "statique-files":

Options +FollowSymLinks  
RewriteEngine on  
RewriteRule ^(.*)$ ../authorize.php?file=$1 [NC]

Et puis dans authorize.php...

if (isLoggedInUser()) readfile('static-files/'.$_REQUEST['file']);
else echo 'denied';

Cette authorize.php fichier est grossièrement simplifiée, mais vous obtenez l'idée.

Solution 2
Créer les suivants .fichier htaccess sous "statique-files":

Order Deny,Allow
Deny from all
Allow from 000.000.000.000

Et puis, ma page de connexion pourrait ajouter que .fichier htaccess avec une adresse IP pour chaque utilisateur qui se connecte. Évidemment, cela aurait également besoin d'avoir une sorte de routine de nettoyage pour purger vieux ou n'est plus utilisé IPs.

---

J'ai peur que ma première solution pourrait être assez cher, sur le serveur que le nombre d'utilisateurs et les fichiers qu'ils accèdent à des augmentations. Je pense que mon deuxième solution serait beaucoup moins cher, mais il est aussi de moins en moins en sécurité en raison de l'usurpation d'adresse IP et etc. J'ai peur que l'écriture de ces adresses IP pour le fichier htaccess peut devenir un goulot d'étranglement de l'application si il y a de nombreux simultanée utilisateurs.

Laquelle de ces solutions sonne mieux, et pourquoi? Sinon, pouvez-vous penser à une solution complètement différente que ce serait mieux que l'autre de ces?

Answer 1

Je voudrais envisager d'utiliser un PHP loader pour gérer l'authentification, puis retourner les fichiers dont vous avez besoin. Par exemple au lieu de faire <img src='picture.jpg' /> Faire quelque chose comme <img src='load_image.php?image=picture.jpg' />.

Votre chargeur d'image peut vérifier sessions, vérifiez les informations d'identification, etc. et ensuite de décider si ou de ne pas retourner le fichier demandé au navigateur. Cela vous permettra de stocker tous vos fichiers sécurisés à l'extérieur de la web accessible de la racine pour que personne ne va juste WGET ou parcourir il y a "accidentellement".

Rappelez-vous juste de retour de la droite des en-têtes en PHP et faire quelque chose comme readfile() en php et qui retourne le contenu du fichier dans le navigateur.

J'ai utilisé cette configuration sur plusieurs de grande envergure site web sécurisé et il fonctionne comme un charme.

Edit: Le système je suis actuellement en train de construire utilise cette méthode pour charger le Javascript, des Images et de la Vidéo, mais le CSS nous ne sommes pas très inquiets à l'obtention d'.

Answer 2

X-Sendfile

Il y a un module pour Apache (et autres serveurs HTTP) qui vous permet de dire au serveur HTTP pour desservir le fichier que vous spécifiez dans un en-tête dans votre code php: Si votre script php doit ressembler à:

// 1) Check access rights code
// 2) If OK, tell Apache to serve the file
header("X-Sendfile: $filename");

2 problèmes:

1. Vous avez besoin d'accéder à des règles de réécriture (.htaccess activé ou l'accès direct aux fichiers de config)
2. Vous avez besoin mod_xsendfile module ajouté à votre Apache installé

Voici une bonne réponse dans un autre thread: http://stackoverflow.com/a/3731639/2088061

Answer 3

J'ai beaucoup pensé à la même question. Je suis tout aussi malheureux avec le moteur PHP en cours d'exécution pour chaque petite ressource qui est servi. J'ai posé une question dans la même veine il y a quelques mois ici, mais avec une orientation différente.

Mais j'ai juste eu un terriblement idée intéressante qui pourrait travailler.

• Maintenir un répertoire appelé /sessions quelque part sur votre serveur web.

• Chaque fois qu'un utilisateur se connecte, créez un fichier texte vide avec l'ID de session en /sessions. E. g. 123456

• Dans votre PHP app, faire des images comme ceci: /sessions/123456/images/test.jpg

• Dans votre fichier htaccess, ont deux rediriger les commandes.

• Celui qui traduit /sessions/123456/images/test.jpg en /sessions/123456?filename=images/test.jpg

• Une deuxième qui traite les appels à l' //sessions/(.*) et vérifie si le fichier spécifié existe à l'aide de l' -f drapeau. Si /sessions/123456 n'existe pas, cela signifie que l'utilisateur s'est déconnecté ou leur session a expiré. Dans ce cas, Apache envoie une 403 ou redirige vers une page d'erreur - la ressource n'est plus disponible.

De cette façon, nous avons quasi-session d'authentification dans le mod_rewrite de faire un "fichier existe" check!

Je n'ai pas assez de la routine pour construire le mod_rewrite déclarations à la volée, mais il devrait être assez facile à écrire. (Je suis à la recherche espérons que dans votre direction @Gumbo :)

Notes et avertissements:

• Session expirée fichiers qui doivent être supprimés rapidement à l'aide d'une tâche cron, à moins qu'il est possible de vérifier un fichier mtime dans .htaccess (qui peut bien être possible).

• L'image / la ressource est disponible pour tout client tant que la session existe, donc pas de protection à 100%. Vous pourriez peut-être contourner ce problème en ajoutant l'IP du client dans l'équation (= le nom de fichier que vous créez) et de faire une vérification supplémentaire par %{REMOTE_ADDR}. Ceci est avancé .htaccess de la maîtrise, mais je suis assez sûr que c'est faisable.

• Url de ressource ne sont pas statiques, et doivent être extraites à chaque fois sur le log-in, donc pas de mise en cache.

Je suis très intéressé par un retour sur ce, tout manque à gagner ou les impossibilités j'ai peut-être négligé, et toutes les implémentations réussies (je n'ai pas le temps maintenant de mettre en place un test moi-même).

Answer 4

Créez une carte de réécriture qui vérifie les informations d'identification de l'utilisateur et les redirige vers la ressource appropriée ou vers une page "accès refusé".

Answer 5

Maintenir le contenu du htaccess ressemble à un cauchemar. Aussi, votre objectif est d'empêcher les non-authentifié utilisateurs non authentifiés les adresses ip des clients d'accéder à ce contenu - si l'approche n'est pas adaptée:

Plusieurs utilisateurs peuvent apparaître à partir de la même adresse IP

Une seule session des utilisateurs peuvent apparaître à venir à partir de plusieurs adresses.

J'ai peur que ma première solution pourrait être assez cher, sur le serveur que le nombre de les utilisateurs et les fichiers qu'ils accèdent à des augmentations de

Si vous voulez éviter que votre contenu provenant de la lixiviation et ne souhaitez pas utiliser HTTP authenitcation puis habillage de tous les accès au fichier dans une couche supplémentaire de la logique est le seul choix raisonnable. Aussi, vous ne savez pas que l'utilisation de PHP pour que cela est un problème - l'avez-vous testé? Je pense que vous seriez surpris de voir combien le débit, il pourrait être de livrer, en particulier si vous utilisez un cache d'opcode.

Je devine votre "simplification" de l'emballage traite de questions telles que le type mime et la mise en cache.

C.