rub a écrit:

A ton avis, il sera possible de gérer un site distant commun à plusieurs sites locaux?

Oui, mais il faudra alors ajouter une étape supplémentaire. C'est-à-dire que quand on génère listing.xml, il faudra également créer un mot de passe propre aux photos que l'on veut partager. Tout utilisateur qui veut profiter de celles-ci doit nous contacter pour qu'on lui donne ce code secret. C'est le prix à payer. Par contre ceci entraîne une implication directe de la personne gérant le site distant. Il faudra le convaincre à mettre en place le système de confidentialité (en gros ça consistera à un simple fichier php puis un mot de passe quelque part).

rub a écrit:

Il est toujours possible d'appliquer différentes méthodes suivant les types d'objets.

Je ne connais pas vraiment comment fonctionnent les .htaccess, mais si on utilise le simple "deny from all", on ne pourra jamais accéder aux fichiers autrement que par un readfile (ou équivalent). Il faudrait alors adapter le .htaccess afin d'empêcher tout accès aux images, mais pas au reste. Mais nos fichiers vidéos ne sont alors pas protégés.

Où est-ce que je veux en venir avec tout ça ? Plus ça va, plus je me rends compte que les besoins sont différents et que du coup, une confidentialité parfaite n'est pas gérable sans en payer le prix en tèrme de charge sur le serveur...

rub a écrit:

Pourrais-tu nous faire un MOD avec en option l'utilisation du readfile pour les sites distants?

Tout est possible :). Ceci dit, pas avant la fin de la semaine prochaine, puisque je serai pas mal occupé bientôt.

Je viens d'avoir une meilleure idée en ce qui concerne les sites distants. Le principe de base reste le même, il faut un secret 's' que seuls le serveur distant Y et les personnes qui veulent y accéder (par là j'entends les serveurs qui hébergent PHPWG), gardons la lettre X pour en représenter un.

Le client veut voir une image venant du site distant Y et fait la demande à X (par l'intermédiaire de getFile.php). Ce dernier calcule le hashage de (Adresse IP du client + timestamp Unix 'T' + image [soit l'ID, soit le nom, je n'ai pas encore regardé le contenu de listing.xml + mot de passe), ce qui sera la clé de session K. X redirige donc le client vers Y en passant en paramètre le triplet (T, K, ID image). Y vérifie que tout va bien (il a l'adresse IP du client, le timestamp, l'ID de l'image puis le secret 's') et si oui, il envoie l'image au client.

L'adresse IP peut être remplacée par le nom d'utilisateur sur X (une adresse IP n'étant pas vraiment unique, mais dans ce cas il faut envoyer le nom d'utilisateur aussi à Y en clair). L'intérêt du timestamp est de ne pas autoriser l'accès à l'image si la demande a été faites il y a trop longtemps (en gros, si on ne fait pas ce test, l'utilisateur peut enregistrer la clé de session puis la réutiliser plus tard).

On pourrait aussi utiliser un algorithme cryptographique pour chiffrer les données ci-dessus. Ainsi nul besoin de transmettre toutes les données en clair, sauf peut-être le timestamp.

Cette méthode a l'intérêt d'éviter la communication entre X et Y avant que le client puisse enfin accéder à l'image. Mais bon, rien de concret pour l'instant, je cherche toujours une approche, celle-ci me semblant assez intéressante.

Bien évidemment, ce n'est pas une sécurité parfaite que je propose là. Puis peut-être qu'il y a un détail très bête qui m'échappe, mais j'ai le temps de réfléchir sur la question... Tout commentaire est bien évidemment le bienvenu.

rub a écrit:

Plusieurs questions:
  o quel mot de passe? A quoi sert-il?
  o comment Y va vérifier les paramètres passés? Par comparaison du hash?

1) le mot de passe est le secret commun 's'
2) exactement ; Y a toutes les données nécessaires au calcul du hash qu'il peut ensuite comparé avec K. Si finalement on utilise une fonction de chiffrage, il a juste à déchiffrer avec 's' puis vérifier que le résultat est cohérent.

rub a écrit:

Par contre, le site Y ne doit pas avoir qu'un secret mais plusieurs secrets, un pour chaque site X.

Le secret peut-être aussi dynamique, suivre certaines regles simples ([id pair, impair], [suivant le jour du mois], etc.)

Pas forcément en fait. Je pense que le secret peut être attaché à la collection de photos mises à disposition.

rub a écrit:

Les secrets seront dans un fichier texte  du serveur Y? Le create_listing_file.php pourrait presque permettre de mettre à jour un secret, (sous réverse bien entendu que le create_listing_file.php soit accesible par X que dans une durée limitée).

Oui un fichier texte sera utilisé et inaccessible de l'extérieur grâce à un .htaccess. En ce qui concerne l'utilisation de create_listing_file pour la distribution du secret, si aucune intervention de la part du gérant du serveur Y n'est demandée, tout le monde peut obtenir le secret et accéder ainsi à la gallerie. Pour l'instant je ne vois pas de moyen intelligent pour faire autrement, et sincèrement, je crois qu'on sera obligé de passer par une intervention humaine.
Un mot de passe dynamique pourrait simplifier la tâche, mais qui dit secret dynamique, dit opération tout à fait duplicable par n'importe qui. Il faut une donnée qui reste cachée du client, connue seulement par Y et (les) X.

rub a écrit:

Dans ce que tu proposes, il faut passer le nom de l'image au getfile.php de Y.
Imaginons que lors de la synchro avec create_listing_file.php, on crée un fichier avec les colonnes (nom complet de l'image, md5 de ce nom complet).
Du côté X, on connait le nom complet de l'image et donc le md5 associé.
Notre secret est donc ce fameux MD5.
En plus, ca permet de ne pas divulger le nom complet de l'image.

En effet, je viens de regarder un listing.xml et aucun champ ID n'est présent. C'est plutôt facheux, il faudra donc modifier ces fichiers, mais alors de manière à rester compatibles avec des versions de PHPWG qui n'utilisent pas le MOD. L'idée d'utilisation du hash du nom de l'image est intéressante, à suivre...

Sur ce, je vous dis bonne nuit :)

P.S: Je ne suis pas sûr d'avoir entièrement compris ta proposition, mais il me semble qu'on est plus ou moins d'accord...

Dernière modification par acp (2006-10-12 00:06:58)

Salut

desole de vous couper sur votre lancée ... mais moi je suis plus terre a terre et je voulais voir
si on pouvais reparler du probleme du calendrier !
et aussi de la partie admin ...

et enfin des fameux tests d'existances de variables.


1) les testes a rajouter d apres moi

  // Do we want the thumbnail of the picture ?
if (isset($_GET['thumb']))
  if ($_GET['thumb'] == 1)
    $row['path'] = substr_replace(get_filename_wo_extension($row['path']),
                          '/thumbnail/'.$conf['prefix_thumbnail'],
                          strrpos($row['path'],'/'),
                          1).'.'.$row['tn_ext'];

  // Do we want the HD version of the picture ?
if (isset($_GET['highdef']))
  if ($_GET['highdef'] == 1)
    $row['path'] = dirname($row['path']).'/pwg_high/'.basename($row['path']);

2) le calendrier :
en fait quand tu te mets dans la vu du calendrier avec les photos en miniatures, c est les photos en direct !!!
et nom par le biais de getfile.php
voir le fichier = calendar_monthly.class.php

3) partie admin :
je ne sais pas si ca serai utile mais je pense que sur la meme idee que le reste il faut gerer l affiche des pages d admin par le getfile aussi


a+

je savais pas trop car si tu vas la c est que t es admin ... donc je me disais que peut etre c etait inutile !

enfin voila c est cool de me repondre  ;o)

sinon pour le calendar ??? tu en penses quoi ?

a+

acp a écrit:

je risque de m'absenter pendant une bonne petite semaine, donc d'ici là ça ne bougera probablement pas beaucoup.

Ok

acp a écrit:

1) Déjà les tests à rajouter, en effet j'ai oublié, ce sera fait pour la prochaine version...

Ok

acp a écrit:

2) Si tu pouvais s'il-te-plaît Nicco me dire de quel calendrier tu parles exactement ? En fait, je ne connais que les fonctionnalités de bases de PHPWG (enfin plus ça va plus j'en apprends là, mais bon) du coup, des calendriers j'en vois partour :). Si je clique sur le lien "Calendrier" à gauche dans le menu de navigation, rien n'apparaît donc c'est peut-être de ça dont tu parles. Indique-moi les liens à cliquer (ou l'URL plus simplement) pour que je vérifier sur mon installation voir ce que ça donne.

Si tu cliques sur l'appareil photo en gaut à droite à la présentation des galeries.
exmple:
http://demo.phpwebgallery.net/index.php … nthly-list

acp a écrit:

3) Hmmm, getFile pour la partie admin. Ça se discute à mon avis. Disons que l'admin a le pouvoir absolu..... A non en fait ça ne se discute pas tiens. Si on ne passe pas par getFile, on ne voit rien à cause du .htaccess c'est ça ? Bon, bah c'est réglé, faut changer ça aussi :).

J'allais justement rajouter la même remarque.
C'est pas qu'on a le choix mais c'est que c'est nécessaire.
Mais même, perso, je pense qu'il appliquer la même méthode partout.

acp a écrit:

Bon weekend !

Bon week-end!



Sinon, je me suis dit que le getfile du site distant, on devrait passer la version en paramètre pour savoir si le script est compatible ou pas.
Le fichier getfile.php du serveur distant pouvant être compatible et utlisée par différentes versions de pwg des sites locaux.

On devrait aussi eviter de donner le même nom au script getfile du site local et du site distant!?

Nicco a écrit:

en discutant aujourd hui, une idee est venu a propos de secureimage ... on ne pourrait pas l'activé que sur certaines categories seulement !

Avec qui tu discutais de ça, entre autres choses, à midi?    8-)

Bonsoir,

en effet, le "blanc" sera prolongé un peu, je n'ai pas trop le temps ces jours-ci de m'occuper de ça. Normalement ce weekend je devrai m'y remettre, mais je ne garantie rien.

Pour ce qui est de l'utilisation que dans certaines catégories, en effet je crois qu'on en avait parlé plus tôt (ou alors l'idée m'avait traversé l'esprit). Si la catégorie/image est publique, on renvoie directement à l'image. Seul problème, le fichier .htaccess... Ceci impose que chaque catégorie (physique) qui est publique doit avoir un .htaccess qui "ouvre" l'accès direct aux images. Mais ça ne fonctionne alors pas avec les catégories virtuelles, etc. Donc c'est quelque chose qu'il faudrait revoir, mais je pense qu'à la longue ça peut s'avérer assez pénible à maîtriser du fait de la gestion actuelle des plugins dans PWG qui ne rend pas les développement/installation/mise à jour très faciles.

Je pense que pour l'instant je vais continuer le chemin emprunté, à savoir corriger les quelques bugs (images dans la partie administration si je ne me trompe pas, et quelques autres disfonctionnements), puis après je me pencherai au problème des sites distants. Une fois que tout ceci tournera de manière satisfaisante, je pense que la question d'une gestion plus fine telle que vous la proposez sera le numéro un dans la liste des choses à faire.

acp