Piwigo.org

acp · 2006-10-07 20:24:34

Alors voilà, un peu de nouveau (mais pas encore dispo, il faut que je teste le tout pour être sûr que ça passe).

- Version pour 1.6.1 prête
- Petites corrections (on n'a par exemple pas besoin de la catégorie de l'image en paramètre)
- Gestion du cache côté client
- etc., je ne me souviens plus vraiment de tout :)

Je viens de me pencher sur la question des sites distants. A priori, comme ça, c'est impossible. Pour l'instant, je ne vois que deux solutions :

1) Ajout d'un fichier (ex. toto.php) sur le site distant qui sera responsable de communiquer avec getFile.php du site local. Il faudra alors que l'utilisateur puisse être identifié. Ceci est fait par getFile.php normalement, donc à présent faut trouver un moyen pour "convaincre" toto.php qu'on n'essaye pas de le tromper. J'utilise drupal et je sais que l'on peut, si l'on a par exemple un compte sur drupal.org, se connaicter sur d'autres sites (qui le permettent) avec son login drupal.org. Donc en gros, si j'essaye de me connecter sur site_drupal.fr avec acp@drupal.org, celui-ci contacte drupal.org et m'authentifie comme ça. Je n'ai pas regardé le code source et je me demande comment on peut y arriver de manière sécurisée, mais bon, l'essentiel c'est que c'est possible

2) Pour toute personne voulant accéder ajouter un de mes répertoires dans ces sites distants, je crée une sorte de "compte". Si X veut ajouter un de mes répertoires dans son album en tant que site distant, il faut que je lui donne un mot de passe propre à lui (d'où le tèrme de "compte"). A chaque fois qu'un utilisateur de X veut voir une de mes photos, X se charge de faire toute l'authentification de son côté, et si tout semble correct il me demande de lui envoyer l'image, en ayant au préalable envoyé le mot de passe commun. Comme le site distant n'a pas de base mysql (pas forcément du moins), on travaille avec des fichiers xml (cf. listing.xml).

Quoi qu'il en soit, site distant mis à part, j'aimerai tout de même corriger un des propos ci-dessus :

rub a écrit:
que les serveurs gardent la même charge

La charge ne sera pas la même, ça malheureusement c'est inévitable. Après par contre, il faudra voir si le surcoût est raisonnable ou non. Une fois que j'aurai atteint un MOD satisfaisant (sans support de sites distants pour l'instant), c'est-à-dire avec un peu de chance demain, je ferai des tests pour voir ce que ça donne. Mais si l'on se fie déjà aux premiers résultats donnés précédemment, on a 1/3 de requêtes en moins avec la vérification des droits d'accès, et ce juste pour une photo. Si à présent on essaye de charger une page de catégorie avec, par exemple, une vingtaine de miniatures, et bien c'est 20 vérifications qui nous attendent.

Si phpwebgallery s'adresse aussi à des sites étant soumis à un nombre très important de requêtes (une petite 100aine d'utilisateurs différents par minute, regardant en moyenne 2 à 3 pages, avec 15 minitiatures chacunes), là un problème de performances peut se poser (pour un site hébergé sur un serveur mutualisé par exemple). Mais si on a une visite par jour, ce serait dommage de laisser porte ouverte à tous.

Qui plus est, un petit défaut auquel j'ai pensé, si l'utilisateur a une petite connexion (un 56K par exemple, si je vous assure ça existe encore), le chargement d'une image par getFile.php peut s'avérer trop long et supérieur à une éventuelle limite de temps d'exécution imposée par notre hébergeur (je pense à Free).

Où est-ce que je veux en venir ? Certes, c'est une fonctionnalité qui pour certains d'entre nous est considérée comme absolument nécessaire, mais quelle que soit la stratégie de l'équipe de phpwebgallery dans l'avenir, il me semble important de laisser l'option à l'utilisateur de désactiver ce mode "sécurisé".

acp · 2006-10-08 12:16:50

Ça y est, j'ai testé tout un peut tout ça pour voir l'impact sur les performances. Tout d'abord les données brutes :

_ PHPWG 1.6.1, normal, aucune modification

20 users, 1M
Transactions: 1567 hits
Availability: 100.00 %
Elapsed time: 61.50 secs
Data transferred: 109.27 MB
Response time: 0.21 secs
Transaction rate: 25.48 trans/sec
Throughput: 1.78 MB/sec
Concurrency: 5.29
Successful transactions: 1270
Failed transactions: 0
Longest transaction: 1.87
Shortest transaction: 0.00

40 users, 1M
Transactions: 2653 hits
Availability: 100.00 %
Elapsed time: 92.49 secs
Data transferred: 183.97 MB
Response time: 0.59 secs
Transaction rate: 28.68 trans/sec
Throughput: 1.99 MB/sec
Concurrency: 16.85
Successful transactions: 2151
Failed transactions: 0
Longest transaction: 23.42
Shortest transaction: 0.00

60 users, 1M:
Transactions: 3245 hits
Availability: 100.00 %
Elapsed time: 112.02 secs
Data transferred: 224.27 MB
Response time: 0.92 secs
Transaction rate: 28.97 trans/sec
Throughput: 2.00 MB/sec
Concurrency: 26.70
Successful transactions: 2696
Failed transactions: 0
Longest transaction: 29.92
Shortest transaction: 0.00

_ PHPWG 1.6.1 avec secureImages 0.2

20 users, 1M
Transactions: 1274 hits
Availability: 100.00 %
Elapsed time: 76.76 secs
Data transferred: 150.92 MB
Response time: 0.61 secs
Transaction rate: 16.60 trans/sec
Throughput: 1.97 MB/sec
Concurrency: 10.05
Successful transactions: 1072
Failed transactions: 0
Longest transaction: 29.97
Shortest transaction: 0.03

40 users, 1M:
Transactions: 1614 hits
Availability: 100.00 %
Elapsed time: 97.35 secs
Data transferred: 190.13 MB
Response time: 1.35 secs
Transaction rate: 16.58 trans/sec
Throughput: 1.95 MB/sec
Concurrency: 22.42
Successful transactions: 1383
Failed transactions: 0
Longest transaction: 53.98
Shortest transaction: 0.03

60 users, 1M:
Transactions: 1011 hits
Availability: 100.00 %
Elapsed time: 60.40 secs
Data transferred: 107.60 MB
Response time: 2.81 secs
Transaction rate: 16.74 trans/sec
Throughput: 1.78 MB/sec
Concurrency: 46.95
Successful transactions: 876
Failed transactions: 0
Longest transaction: 26.35
Shortest transaction: 0.06

Ce qu'on peut en déduire, c'est que les performances en mode sécurisé sont de 2/3 du mode normal (attention, pour les tests avec 60 utilisateurs, regardez bien le temps d'exécution, vous verrez qu'en mode normal, pour une raison qui m'échappe le test a duré 110s, soit le double qu'en mode sécurisé. Le test consistait à charger la page d'accueil, où ne figure qu'une seule catégorie. Ensuite, on charge cette dernière qui ne contient que 4 images, qu'on ouvre successivement les unes après les autres. Puis on recommence. Le cache n'est pas pris en compte, dans aucun des deux modes (je ne peux pas malheureusement mesurer l'impact que ceci aurait), mais au final le rapport 2/3 resterait le même.

Il s'agit là de tests assez gourmants en ressources. 20, 40, puis 60 utilisateurs qui demandent toutes les secondes une nouvelle image. Comme je l'ai dis précédemment, si la gallerie est massivement visitée, l'utilisation du MOD est à revoir. Mais je doute que les personnes ayant plus d'une centaine de visiteurs par jour soient nombreuses. Puis si l'on a tant de visiteurs, il est très probable qu'une grande partie de notre gallerie soit publique auquel cas, nul besoint du MOD. Si la fonctionnalité devrait se voir intégrée dans PHPWG, il serait peut-être intéressant de créer une fonction (modifier get_thumbnail_src pour les miniatures) qui renvoit un lien direct vers l'image si la catégorie dans laquelle elle se trouve est publique ou un lien vers getFile.php pour le reste.

Nicco · 2006-10-08 16:02:29

Salut et surtout merci de travailler sur ce theme car moi j utilise une double authentification
phpwebgallery + http en apache pour l acces au fichier !!!

mais c est la galere ... htpassword a maintenir

maintenant j ai eu des problemes ... enfin J AI DES PROBLEMES

deja :

PHP Notice: Undefined index: highdef in ....\\modules\\secureImages\\getFile.php on line 43

ligne 43 dans le getfile.php

j ai rajouté un test pour eviter une erreur
// 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']);

maintenant j ai aussi ca :

PHP Fatal error: Call to undefined function mime_content_type() in ....\\modules\\secureImages\\getFile.php on line 64, referer: ..../index.php?/category/353

et la je ne sais pas

bon en fait je voudrai savoir si il y a des choses speciales a faire car la ma galerie n affiche plus aucunes photos merci d avance

acp · 2006-10-08 16:21:00

Bonjour,

au sujet de l'erreur highdef, c'est étrange que ça génère une erreur. Il faudrait que j'ajoute quelques lignes de vérifications tout de même (du type is_numeric, etc.).

En ce qui concernen le mime_type_content, tu dois sûrement être hébergé chez free. Je n'avais pas testé avant de mettre la nouvelle version en ligne. Il s'avère que cette fonction n'est pas accessible (pourtant elle devrait, je ne vois pas trop pourquoi). Quoi qu'il en soit, si t'es bien chez free (ou autre fournisseur d'accès tournant sous un système de type unix), j'ai mis en ligne une nouvelle version (toujours numérotée 0.2, mais si tu regardes le changelog il y a une ligne supplémentaire) qui corrige pour l'instant ce problème.

Si t'es sous un serveur Windows, ou le problème est toujours là, je ne peux que te conseiller d'enlever le MOD jusqu'à nouvel ordre. Je pense (puisqu'il semble que ça sera à un moment ou à un autre un souci) passer outre cette fonction et tout bêtement utiliser les extensions des fichiers pour récupérer l'info que je souhaite avoir.

Bon courage :)

Parenthèse, j'en profite pour signaler à ceux qui ont une gallerie dont le bon fonctionnement est impératif, ne "jouez" pas encore avec ce module, il n'est qu'en "bêta".

rub · 2006-10-08 16:39:32

acp a écrit:
Quoi qu'il en soit, site distant mis à part, j'aimerai tout de même corriger un des propos ci-dessus :
rub a écrit:
que les serveurs gardent la même charge
La charge ne sera pas la même, ça malheureusement c'est inévitable. Après par contre, il faudra voir si le surcoût est raisonnable ou non.
....

Je mettais mal exprimé mais c'est bien de ce que je pensais, tu as bien fait de refaire le point.

acp a écrit:
Où est-ce que je veux en venir ? Certes, c'est une fonctionnalité qui pour certains d'entre nous est considérée comme absolument nécessaire, mais quelle que soit la stratégie de l'équipe de phpwebgallery dans l'avenir, il me semble important de laisser l'option à l'utilisateur de désactiver ce mode "sécurisé".

Tout à fait d'accord!
Je pense même que ce n'est pas une option à désactiver mais plus une option à activer... si tu vois ce que je veux dire....

Pour les sites distants, il faut voir aussi que actuellement un site distant peut-être utilisé par n galeries en même temps... est-ce que va encore possible en mode sécurisée? A voir....

bientôt, je teste ton MOD

Nicco · 2006-10-08 16:45:16

Salut et merci pour l aide !!!

maintenant que tu m as eclairé sur mime_type ...

je m heberge moi meme et du coup je suis allé voir mon php.ini

--> extension=php_mime_magic.dll

voila maintenant c est ok plus une erreur !!!

par contre j ai plein de photos qui ne s affiche pas

je voulais juste savoir comment cela fonctionne ... et si le probleme ne peut pas venir du fait que j utilise de multi groupe

merci d avance pour l aide !

acp · 2006-10-08 16:54:15

Je ne sais pas ce que tu entends par multi groupe, si tu pouvais me filer un peu plus d'infos à ce sujet.
Pour ce qui est des problèmes d'affichage, le meilleur moyen de voir ce qui ne va pas est d'essayer d'afficher l'image toute seule.

Nicco · 2006-10-08 17:03:20

re bonjour,

juste pour info je continue a tester !!! et en fait j ai le probleme de vignettes qui ne s affiche pas avec les categories virtuelles

donc peut etre verifier le systeme de verif des droits et celui des cat virtuelles

a+

acp · 2006-10-08 17:31:17

J'ai testé vite fait sur mon install locale en créant vite fait une catégorie virtuelle et en y mettant deux images. Tout se passe bien, que je sois connecté ou pas.
Tu dois avoir une gallerie un peu particulière. Si tu pouvais essayer de me donner une idée de la structure qui pose problème, question que j'essaye de la dupliquer chez moi pour voir ce qu'il en est.

Sinon, ce n'est que les vignettes qui ne s'affichent pas ? L'image, peut-elle être visualisée ?

Nicco · 2006-10-08 17:34:47

ok voici mon site !!!

http://test-nicco.no-ip.org/index.php?/categories

si tu veux venir tester le resultat

et apres on en reparle ... pour essayer de réglé ca

Nicco · 2006-10-08 17:49:04

donc après quelques t es en fait a chaque fois que j ai fais une categorie virtuelle pour donner acces a quelques photos d une autre categorie ou la je ne donne pas les acces : ca ne marche pas

en fait dans mon idee souvent je cree une cat virt pour partager seulement les photos de vacances de payages ... etc ... et j utilise la categorie d origine pour les proches et moi

voila l idee et donc je pense que le module getfile.php doit chercher les acces par rapport a la cat d'origine et pas par la virtuelle ????

a+

acp · 2006-10-08 18:34:43

Oui là je vois... C'est bel et bien ça. Initiallement, je récupérai l'identifiant de la catégorie ET celui de l'image. Mais ne voyant pas l'utilité, je l'ai enlevée... En gros, ce qu'il faut changer à présent c'est tous les appels de getFile et rajouter l'identifiant de la gallerie, puisque dans getFile je ne regarde que celle qui est physique.

J'ai fait quelques modifications mais c'est un peu délicat, je vais devoir modifier un peu plus le code de PHPWG. Je vais voir ce que je peux faire pour minimiser les interventions dans category_subcats.inc.php, le fichier qui pose le plus de problèmes actuellement.

EDIT:
Une option serait d'utiliser la fonction 'calculate_permissions' dans 'include/functions_user.inc.php' pour avoir la liste des catégories interdites à l'utilisateur, puis la comparer avec la liste des catégories auxquelles appartient l'image qu'il veut visualiser. Ça commence à faire beaucoup d'appels à la BD pour une tâche assez simple à mon avis.
L'autre option me semble plus adapté, mais nécessite un bon nombre de modifications au code de PHPWG (enfin comme ça, d'après ce que j'ai cru voir)...
Si un codeur de PHPWG voit une solution qui m'échappe, n'hésitez pas à la proposer... Entre temps, les catégories virtuelles risquent de ne pas avoir de vignette...

Dernière modification par acp (2006-10-08 18:43:37)

Nicco · 2006-10-08 18:43:19

ok chef !

moi je reste pas loin de mon mail comme ca je test car je suis vraiment interesse ... du coup tu me dis je fais des tests avec toi sur le sujet

Graou · 2006-10-08 21:10:46

acp a écrit:
Puis si l'on a tant de visiteurs, il est très probable qu'une grande partie de notre gallerie soit publique auquel cas, nul besoint du MOD.

Je pense que c'est justement l'inverse.

Si il y a bcp de visite, sauf événementiel, ça doit vouloir dire que c'est un site "professionnel", et je pense que les quelques pros utilisant l'outil (comme moi, sauf que j'ai pas tant de visites que ça :-)) utilisent presque tous les catégories virtuelles, pour une raison ou pour une autre.
vimages les utilise, je les utilise pour séparer éditing et photos à la vente, et il y a surement plein d'autres utilisations.
Ce sont même ces "gros" sites, à mon avis, qui seraient le plus intéressés par ça : qu'un client ne puisse pas aller voir les images destinées à un autre.

Cordialement,

Philippe LAGARDE

P.S. Question naïve : il n'y a pas moyen de générer tout simplement un .htacces dynamique?

rub · 2006-10-08 21:44:18

Graou a écrit:
acp a écrit:
Puis si l'on a tant de visiteurs, il est très probable qu'une grande partie de notre gallerie soit publique auquel cas, nul besoint du MOD.
Je pense que c'est justement l'inverse.

Si il y a bcp de visite, sauf événementiel, ça doit vouloir dire que c'est un site "professionnel", et je pense que les quelques pros utilisant l'outil (comme moi, sauf que j'ai pas tant de visites que ça :-)) utilisent presque tous les catégories virtuelles, pour une raison ou pour une autre.
vimages les utilise, je les utilise pour séparer éditing et photos à la vente, et il y a surement plein d'autres utilisations.
Ce sont même ces "gros" sites, à mon avis, qui seraient le plus intéressés par ça : qu'un client ne puisse pas aller voir les images destinées à un autre.

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!).

Graou a écrit:
P.S. Question naïve : il n'y a pas moyen de générer tout simplement un .htacces dynamique?

Surement,! Ca peut être aussi une solution mais l'authentification par .htacces nécessite peut-être une double connection

Piwigo.org

Annonce

#16 2006-10-07 20:24:34

Re: Accès direct au images

rub a écrit:

#17 2006-10-08 12:16:50

Re: Accès direct au images

#18 2006-10-08 16:02:29

Re: Accès direct au images

#19 2006-10-08 16:21:00

Re: Accès direct au images

#20 2006-10-08 16:39:32

Re: Accès direct au images

acp a écrit:

rub a écrit:

acp a écrit:

#21 2006-10-08 16:45:16

Re: Accès direct au images

#22 2006-10-08 16:54:15

Re: Accès direct au images

#23 2006-10-08 17:03:20

Re: Accès direct au images

#24 2006-10-08 17:31:17

Re: Accès direct au images

#25 2006-10-08 17:34:47

Re: Accès direct au images

#26 2006-10-08 17:49:04

Re: Accès direct au images

#27 2006-10-08 18:34:43

Re: Accès direct au images

#28 2006-10-08 18:43:19

Re: Accès direct au images

#29 2006-10-08 21:10:46

Re: Accès direct au images

acp a écrit:

#30 2006-10-08 21:44:18

Re: Accès direct au images

Graou a écrit:

acp a écrit:

Graou a écrit:

Pied de page des forums