Autan pour moi.
Merci pour la reponse.

Oui, j'ai la même préoccupation.

Un visiteur à qui j'ai donné un compte va se connecter sur une gallerie virtuelle à laquelle il a accès et voir des images. Là, il peut choisir, dans le menu contextuel de son navigateur "afficher l'image". Il se retrouve alors en accès direct de l'image dans sa catégorie réelle.

A partir de là, il peut facilement deviner le nom des autres images, d'autant plus que, s'agissant de photos numériques, elles ont un nom du type DSC000123.JPG !

Je ne veux pas mettre des catégories réelles selon les groupes d'utilisateurs pour des raisons évidentes (c'est le boulot des catégories virtuelles). Voici donc ma question:

comment pourrais-je empêcher l'accès direct aux fichiers des catégories réelles sans passer par phpwebgallery, simplement en tapant l'adresse dans la barre d'adresse du navigateur ?

Le problème me semble d'autant plus grave que ceci peut s'appliquer à tout le monde, et pas simplement aux utilisateurs qui auraient un compte sur ma galerie... Déjà une solution partielle serait d'empêcher l'accès à quiconque n'est pas loggé dans phpwebgallery.

Or, si je ne m'abuse, cela ne peut se faire qu'en interfaçant la base de donnée utilisée avec la gestion d'un .htaccess, corrigez-moi si je me trompe... Une idée ?

Monsieur Dusnob a écrit:

[...]Or, si je ne m'abuse, cela ne peut se faire qu'en interfaçant la base de donnée utilisée avec la gestion d'un .htaccess, corrigez-moi si je me trompe... Une idée ?

Je sais assez bien ce qu'est un .htaccess (ou un httpd.ini pour certains), je sais encore mieux ce qu'est une base de donnée...
Mais interfacer les deux, je ne vois pas.
Aurais-tu un lien expliquant les possibilités éventuelles d'interface à nous proposer de consulter?
Merci de ton éclairage.

Dans mon raisonnement j'en suis là:
.htaccess va gérer soit des accès, soit du rewriting d'URL.
Coté accès, je ne vois pas à quoi cela va servir de mettre d'interdire des accès, étant donné qu'il faut arriver à montrer les photos.
Seul le rewriting pourrait nous protéger (? j'en doute).
Imaginons que PWG soit en phase avec des règles de rewriting.
PWG demande l'image RVC00012C.JPG et .htaccess reroute la demande sur DSC000123.JPG...
En accès direct depuis le navigateur, l'utilisateur demande RVC00012C..JPG et aussi complexe soit l'algorithme de rewriting dans 10/15 ou 20 photos, l'utilisateur saura quels sont le(s) JPG manquant(s) et pouvant être éventuellement affiché(s)/récupéré(s).

Il n'y a pas à ma connaissance de solution parfaite.
Le nom aléatoire est une bonne solution mais très imparfaite.
Et en tout état de cause les solutions à peu près correctes résident dans un travail de classification des photos.

1 - Travail de renomage des photos (sans créer de série, cad. pas de DSC000123.JPG, DSC000124.JPG, DSC000125.JPG, ... mais genre RVC00012C.JPG, VPC00012E.JPG, PGC00012G.JPG, etc...).
= un programme aléatoire. Ça existe...

2 - Travail de reclassement en catégories réelles (toutes privées et surtout sans la moindre autorisation groupe ou utilisateur), exemples:
avril-2005/public
avril-2005/prive-a
avril-2005/prive-b
avril-2005/prive-s
avril-2005 sera considéré comme le répertoire d'une mise à dispo de nouvelles photos.
= un programme de classement rapide sur base de browser

3 - Travail de reclassement en catégories virtuelles (Celles qui seront être visibles suivant les autorisations), exemples :
La catégorie virtuelle "Grand public"  (catégorie publique) est composée uniquement des images de "public" de toutes les périodes d'arrivage de  photos.
La catégorie virtuelle "Abonnés" (catégorie privée) est composée des images de toutes les "prive-a".
La catégorie virtuelle "Bonus" est composée des images de toutes les "prive-b".
La catégorie virtuelle "Super bonus" est composée des images de toutes les "prive-s".
z0rglub et l'équipe travaille sur le caddie qui devrait nous permettre le classement rapide en catégorie virtuelle.

4 - Les groupes d'utilisateurs, et leurs droits. exemple:
Le groupe "Abonnés" a les droits sur "Abonnés".
Le groupe "Cotisants" a les droits sur "Abonnés" et "Bonus".
Le groupe "Bureau" a les droits sur "Abonnés", "Bonus" et "Super Bonus".
Tache manuelle, car chacun à sa structure (en général très très simple).

5 - Enfin de course, tu as aussi le marquage des photos. Ce n'est pas complètement stupide, même si là encore, il y a des limites.


Bref, si tu as un lien expliquant les possibilités éventuelles d'interface .htaccass à nous proposer de consulter, il y aura des preneurs sans doute.

Dernière modification par VDigital (2005-06-15 08:24:11)

Bonjour,
Je viens de découvrir phpwebgallery (notament parceque free me l'a proposé en option). Je suis donc nouveau sur ce forum et je me suis déjà posé cette question quand j'ai codé ma propre gallery de photo.
On peut donc :
1/ utiliser des noms aléatoires + un fichier .htaccess
2/ Interdire tout accès exterieur au site aux photos.

1/ Pour éviter l'accès a toute une catégorie on peut utiliser un fichier .htaccess (certains propose un fichier index.html mais cette solution est très mauvaise puisque le plus bête des aspirateurs de site permettra de récupérer les photos en un temps record).
Dans ce fichier .htaccess on pourra mettre le code suivant :

Options -Indexes

Cela aura pour effet d'interdire le listage du répertoire qui contient le .htaccess ainsi que tous ses sous répertoires. Avouez que c'est mieux que de placer un fichier index.html, inutile de surcroit, a chaque ajout de catégorie.

Reste encore la possibilité à un curieux de saisir le nom de la photo directement dans l'url. Et si les noms de photos s'incrémentent comme c'est le cas la plupart du temps il est vite fait pour ce petit curieux d'avoir toutes les photos des catégories dont il a connaissance. On peut donc choisir un nommage aléatoire des photos. Bien sur plus la partie aléatoire du nom de la photo est grande plus la sécurité est grande. On pourra par exemple mélanger chiffres et lettres mais aussi minuscule et majuscule. On pourra pour cela utiliser un petit logiciel. Perso je n'en connais pas. J'ai donc commencé à en faire un mais ca avance pas vite lol.
Par exemple : Photo_01afA4Efr41.jpg sera plus dur a trouvé que Photo_01a0.jpg.

2/Pour interdire tout accès exterieur au site on utilise également un fichier .htaccess qui contient le meme code que le précédent fichier mais aussi un autre plus compliqué qui vérifie le referer. Si celui ci n'est pas notre site l'accès est refusé. Techniquement ça veut dire que toutes les urls directement saisies dans le navigateur seront refusées et que l'utilisateur doit utiliser un lien du site pour y accéder. Je ne sais pas si techniquement il est possible de modifier le referer à sa guise. Si c'est le cas niveau sécurité les deux méthodes doivent être grosso modo les même. Si ce n'est pas le cas celle ci serait donc en béton. Petite note aux abonné(e)s free, les directives utilisées dans ce fichier .htaccess ne fonctionnent pas sur l'espace web de free désolé.

Options -Indexes
SetEnvIfNoCase Referer "^http://monsite.com/" locally_linked=1
SetEnvIfNoCase Referer "^http://monsite.com$" locally_linked=1
SetEnvIfNoCase Referer "^monsite.com/" locally_linked=1
SetEnvIfNoCase Referer "^monsite.com$" locally_linked=1
<FilesMatch "\.(png|jpe?g)$">
  Order Deny,Allow
  Allow from env=locally_linked
</FilesMatch>

Je ne suis pas sur du code mais au moins ca vous donnera la piste a explorer.

flipflip a écrit:

[...] Mais j'ai lu dans un post qu'un aspirateur aura vite fait de trouver comment grugé le truc, ca fonctionne comme un navigateur, il cherche un fichier index.html, htm, php... si il en trouve un il le lit et [...]

L'apirateur... Beurk.
(Le jour de la fête des pères, c'est comme offrir une casserole à sa tendre et douce compagne le jour de la fête des mères).

Blague à part: Les aspirateurs "de sites" sont plus sophistiqués, ils ne regardent pas que les index à mon avis (en freeware ou payant).

Je n'ai pas d'a priori sur la question:
- je pense que certains doivent en avoir le besoin sur le plan professionnel, et donc ils seront toujours efficaces tant que certains seraient prêts à payer (et je suis convaincu que dans certains secteurs d'activité peu scrupuleux, cela fait parti de l'arsenal classique des moyens dont ils doivent disposer).
- je pense également que d'autres ont évidemment le besoin professionnel de se protéger des aspirateurs, et qu'ils feront mieux qu'aujourd'hui(mais ils partent dans une course à l'échalote, car ils auront sans doute toujours un train de retard).

L'aspirateur est une chose, se protéger en est une autre. Je pense qu'il ne faut pas s'égarer et laisser temporairement l'aspirateur de coté.
Ceci afin de se consacrer à "Que dois-je faire à minima pour ma galerie?"

N'est-ce pas suffisant dans un premier temps?
Quant au code de perverto, je ne suis pas un spécialiste, mais je crois avoir compris l'idée.
Il nous faut quelqu'un qui maitrise la gestion des droits sur serveur.

Il existe une autre solution, stocker les photos directements dans la base dans un champs blob... mais là attention à la taille de la base, perso je gère un site avec 4000 photos, j'ose même pas imaginer la tête de mon hebergeur si je lui annonce que je vais mettre 4000 photos dans sont mysql en mutualisé :)

En gros ca peut être une solution pour gérer de tout petit site mais dans l'autre cas c'est des coups à mettre à genou le serveur en 5 mn.

J'ai refais un test avec Options -Indexes, ca marche en fait même trop bien. Ca marche tellement que PWG ne peut plus lister les images présentes dans un répertoire distant ni même dans un répertoire local. J'en déduit que PWG ne stock pas le chemin+le nom dans la base, mais liste les répertoires à chaque fois, enfin en ce qui concerne les répertoires locaux, pour les distants je vois pas trop.