rub a écrit:

Je ne crois pas que c'est ce que voulait dire acp.
Il voulait,je penses, dire que le fait d'avoir un système sécurisé n'est pas nécessaire dans les galeries où tout les catégories sont publiques (physique ou virtuelle).
Un système sécurisé est pratique pour les sites pro (d'un point de vue commercial) mais aussi pour la "confidentialité" de certains photos privées (la photo des enfants non visibles par tous!).

Oui je pensais plutôt à ça.

Bon alors, je suis en train de régler le problème des catégories virtuelles (voir plus haut). La solution pour laquelle j'ai opté est la suivante. On me demande d'afficher l'image X, je regarde si celle-ci se trouve dans une catégorie qui est accessible à l'utilisateur, j'affiche. Ceci veut dire que si l'image est dans une catégorie (physique) privée à laquelle l'utilisateur n'a pas accès, mais aussi dans une catégorie virtuelle disons publique, on l'affiche.

Pour la suite, je vais essayer de réduire le temps d'exécution. Pour example, j'inclus common.inc.php mais n'ai besoin que d'une ou deux fonctions, donc je vais normalement l'enlevé. Ensuite, étant donné que je vérifie déjà (avec ce que j'ai dis ci-dessus) si l'utilisateur a vraiment accès à l'image qu'il demande, plus besoin de le refaire plus loin, donc ça allège un peu le tout.

Question qui se pose à présent. Il y a moyen également de demander à ce que l'image ne soit pas gardée dans le cache de proxies ou autre (à l'aide de Cache-Control suivi de private ou public, ce qui tombe très bien puisque c'est le status des catégories de PHPWG). Deux inconvénients se présentent toutefois:
1) On doit également faire un JOIN pour la table des catégories (ce qui ralentit la requête)
2) Il se peut que la requête SQL elle-même soit un peu plus complexe.

Est-ce que vous pensez que ça en vaut la peine ?

Bien l'bonjour,

il est en effet possible de récupérer l'identifiant de la catégorie, mais à une exception près (visualisation de sous-catégories, la vignette aléatoire/choisie qui représente la catégorie n'a pas d'identifiant de catégorie qui va avec). Rectifier ça engendrait quelques modifications dans le code de PHPWG ce que je veux éviter à tout prix (je me contente du stric minimum pour l'instant).
Après, même si on connait la catégorie, il faut tout de même vérifier que l'image est bien dans celle-ci, donc au final le gain n'est pas si grand.

Nicco a écrit:

pwg fait deja le tri de ce que tu peux voir ou non ( enfin je crois ) et du coup toi tu ne peux pas rebondir la dessus ?

Malheureusement non, parce que si je ne fais aucune vérification à nouveau, rien n'empêche le visiteur de pointer directement à getFile.php en essayant de jouer un peu sur les paramètres puis accéder ainsi à du contenu normalement privé.

Puis pour les tests, je te tiens au courant si besoin en est ;). Merci de proposer ton aide...

Salut mister ACP

donc deja cool pour la nouvelle version je vais tester ca !!!

+

pour les test des if !!! je l ai fais sur les 2 ... desole pour toi HAHAHHA

et sinon moi je pense que j ai des alertes car mon apache doit etre en mod debbug   ;o)
mais c est mieux non si on corrige ca ?

allez a tout a l heure je vais faire 2 ou 3 test

donc je comfirme que pour le representative il faut utilisé ta fonction sur je ne sais plus quel appel

et la je ragarde pour le calendrier par mois ... mais je capte pas
et j ai un soucis aussi avec ... dernieres categories = pas de thumbnail mais quand je clique de dans ca marche je vois tout !!! bizarre !!!

bon nuit j arrete bye

acp a écrit:

Question qui se pose à présent. Il y a moyen également de demander à ce que l'image ne soit pas gardée dans le cache de proxies ou autre (à l'aide de Cache-Control suivi de private ou public, ce qui tombe très bien puisque c'est le status des catégories de PHPWG). Deux inconvénients se présentent toutefois:
1) On doit également faire un JOIN pour la table des catégories (ce qui ralentit la requête)
2) Il se peut que la requête SQL elle-même soit un peu plus complexe.

Est-ce que vous pensez que ça en vaut la peine ?

Perso, oui!


Pour revenir sur les sites distants, le problème c'est qu'on ne pourra pas activer le .htaccess (enfin, je penses).
Mais l'avantage c'est que les noms et répertoires des répertoires ne seront plus visibles.
Ceci couplé avec des index.php dans chaque répertoire, cela nous donne une meilleure sécurité que ce qui existe actuellement.


Pour resumé:
  Sur le site local:
    o Avantages:
      - avec un .htaccess, la sécurité est totale (Photos accésibles par la galerie uniquement)
      - les noms et répertoires des images ne sont plus visibles/accésibles
    o Inconvénients:
      - Temps de réponses en peu long
      - Plus de réquêtes

  Sur les site local:
    o Avantages:
      - avec des index.php, on évite de lister les répertoires et les images
      - les noms et répertoires des images ne sont plus visibles
    o Inconvénients:
      - Temps de réponses en peu long
      - Plus de réquêtes
      - Pas de protection totale des images du site distant

acp a écrit:

rub a écrit:

Mais l'avantage c'est que les noms et répertoires des répertoires ne seront plus visibles.

Pas exactement. Ceci peut en effet être fait, mais nécessite alors que l'image soit transféré du site distant au site local (en utilisant par exemple fopen) et retransmise par le site local au client. Donc une étape deux fois plus longue. Actuellement, ce que fait le MOD c'est rediriger directement vers l'image sur le site distant, donc on voit son adresse exacte (enfin, pas dans le code html de la gallerie, mais si l'on clique sur VOIR IMAGE par exemple, là on se retrouve directement sur le site distant).

T'es sur?
Car le readfile peut lire des fichiers sur un site distant. (j'ai testé hier car j'ai du faire une modification sur action.php).
Donc, dans ce cas, pas de problème de double charge, etc...

acp a écrit:

Le code php (fopen ou readfile) s'exécute sur le serveur X qui héberge la gallerie. Si le fichier à ouvrir est sur un site Y distant, c'est X qui effectue la lecture, puis donne le résultat final au client.
Je ne dis pas ça en connaissance absolue de PHP, mais je ne vois vraiment pas un autre moyen de fonctionnement, disons que je suis sûr à 99.9% :).

Oui, oui, je me suis embrouillé tout seule...
Mais, il y a peut-être 1% de chance que ca ne fonctionne pas comme ca (même si je crois comme toi que ca va faire double opération)

Je comprends mieux ta précédente explication.
Et c'est vrai qu'on peut avoir le problème du temps d'éxecution.

Et avec header('Location:...', on ne peut pas cacher le nom de l'image? Même dans les propriétés!

Je voudrais quand même savoir comment se comporte exactement le readfile d'un site distant, et si il y a vraiment les données qui passent par du serveur Y au serveur X puis au client et non du serveur Y au client.

acp a écrit:

A en croire la documentation

Tres interessant, tout ca bien que ca n'arrange pas nos affaires.

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

acp a écrit:

A noter que ces solutions présentent un inconvénient non négligeable... On ne peut pas bookmarker le lien vers l'image distante et espérer pouvoir la revoir par la suite... On est obligé de repasser par getFile.php.

Ca, ce n'est pas trop grave pour moi.
La disquette permet de télécharger la photo au format HD et pour moi, c'est suffisant.
Mais effectivement, c'est un point important à noter.

acp a écrit:

Un autre problème dont je me suis rendu compte en regardant la documentation de readfile, il semblerait que TOUT le fichier est chargé en mémoire, puis après envoyé au client. Je ne sais pas comment travaille apache, mais ça m'étonnerait que ce soit ainsi. Si l'on veut donc charger une vidéo en passant par getFile.php, ça risque de ne pas être apprécié par notre hébergeur...

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

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