Discussion :

[Djakisback]

Bonjour,
j'utilise un fichier get.php dans un dossier publié qui lit et retourne une image jpg depuis un dossier non publié. Je l'utilise de la sorte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<img src="get.php?img=12">

Pour bloquer l'accès direct au fichier get.php j'ai ajouté ce .htaccess :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
RewriteEngine on
RewriteCond %{HTTP_REFERER} !http://localhost/.* [NC]
RewriteCond %{HTTP_REFERER} !localhost/.* [NC]
RewriteRule ^get.php$ - [F]

Ça retourne une erreur 403 si on essaie d'accéder à http://localhost/get.php donc ça fonctionne. Mais en fait j'aimerais bien comprendre pourquoi ça ne retourne par une erreur 403 lors de l'appel à <img src="get.php?truc=12"> ?
Le navigateur client fait bien un GET http://localhost/get.php lorsqu'il passe sur la balise image non ?

D'autre part, que pensez-vous de ce type de "protection" pour restreindre l'accès aux images ?
Merci d'avance.

[_Mac_]

Ca fonctionne avec un <img ... parce quand dans ce cas, le navigateur envoie au serveur un en-tête HTTP Referer dans lequel figure l'URL de la page qui appelle cette ressource. Et comme c'est justement cet en-tête qui est vérifié par la configuration que tu indiques, l'accès au fichier est autorisé dans le cas de la présence de cet en-tête et donc est refusé si l'en-tête ne figure pas ou figure mais avec la mauvaise URL.

Au passage, les 2 RewriteCond que tu donnes ne sont pas des plus optimales. J'écrirais plutôt la chose ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^http://localhost/.* [NC]
RewriteRule ^get.php$ - [F]

Le seul souci c'est le passage en production : il faudra que tu changes le "localhost" avant de copier ce fichier sur le serveur de production.

Sinon, oui, cette protection existe bel et bien, ça s'appelle une protection contre le hot linking, mais ça peut rendre le site non fonctionnel pour certains navigateurs ou proxies qui n'envoient pas au serveur l'en-tête Referer pour des raisons de confidentialité.

[Djakisback]

Ah ok, merci ! Je n'avais pas vu que les clients courants envoyaient effectivement le referer dans les headers pour les src (img, css, etc.).
Hm ok, "protection" facile à contourner donc vu qu'il s'agit juste de changer le referer mais c'est déjà pas mal
Pour la RewriteCond :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

RewriteCond %{HTTP_REFERER} !^http://localhost/.* [NC]

je ne connais pas très bien la syntaxe du mod_rewrite, RewriteCond prend bien une REGEX en entrée ? Dans ce cas '^' symbolise le début de chaîne donc comment la condition peut matcher 'http://localhost/.*' et également 'localhost/.*' ?
Est-ce que ce ne serait pas plutôt ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

RewriteCond %{HTTP_REFERER} !^(http://)?localhost/.* [NC]

[_Mac_]

En effet, ^ matche bien le début de la chaîne mais pourquoi veux-tu absolument aussi matcher localhost/.* ? Un Referer bien formé commence nécessairement par http://... : c'est une URL absolue.

[Djakisback]

En fait, j'ai vu ça sur un site et je ne me suis pas trop posé de questions mais après vérification dans la RFC le referer peut être une URI absolue ou relative :

Referer = "Referer" ":" ( absoluteURI | relativeURI )

je vais donc partir sur ça je pense :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

RewriteCond %{HTTP_REFERER} !^(http://)?localhost/.* [NC]

Merci encore pour ton aide

(Hm après réflexion la regex ne matche pas les urls relatives, il faut que je réfléchisse au truc)

[_Mac_]

Ah, bien vu, j'étais convaincu que c'était nécessairement une URL absolue car je n'ai jamais vu que ça.

Pour info, une URL relative n'est pas /localhost/chemin mais /chemin Donc tes parenthèses doivent englober tout le http://localhost.