flop25 a écrit:

-le hotlinking : une attaque ddos est aisée

C'est pas trop mon domaine, mais le hotlinking est possible avec phpthumb! La preuve, j'affiche une image sur le forum tout droit sorti de phpthumb sur mon serveur:

Sauf qu'avec mon script, on ne voit même pas l'url du fichier source... et si on veut vraiment faire quelque chose pour le hotlinking, ça ne doit pas être très compliqué en vérifiant le http référer. Mais bon, quelle est l'intérêt de se protéger du hotlinking pour les miniatures???

Par contre, pourquoi "une attaque ddos est aisée"??

flop25 a écrit:

-on augmente sacrément le nombre de requête sql

Franchement, c'est pas énorme.... je suis sur que mon script est plus rapide que phpthumb...

flop25 a écrit:

Pour résoudre ces deux points serait-il posssible de jouer seulement avec les préfiltres, dans themeconfig sans appel via url

Sans appel via url?? Heu je vois pas comment faire... à par envoyer l'image directement au template encodée en base64, mais ça va faire des sacrées pages à charger!

En relisant ton message, je me suis peut être mal exprimé: à aucun moment je n'affiche l'url de l'image en cache dans le template, c'est exactement le même système que phpthumb.

<img src="./themes/stripped_black_bloc/getthumb.php?id=123&width=150">

flop25 a écrit:

Ha ben une requête par miniature tout de même ! 50miniatures->50requêtes !

C'est même plus qu'une requête par miniature car le common.inc.php est chargé (donc la conf et l'utilisateur aussi). Mais comparé aux accès au filesystem que fait phpthumb, je te garantis qu'il faut mieux faire des requête sql que de vérifier la date des fichiers en cache comme le fait phpthumb!

flop25 a écrit:

Justement, l'idéal serait une gestion mufti-taille interne : les images sont crées dans la galerie (à la wp avec un suffixe 195x110)
Ainsi pas d'appel url, pas de problème de gérer "l'externe", réutilisation par ailleurs et gestion du cache par le navigateur simplement

Je comprend pas...

flop25 a écrit:

L'idéal serait une gestion multi taille afin de ne pas générer à la volée mais apriori. Ton système est très bien -mieux sur certain point que phpthumb- pour générer à la volée, mais en terme de performance, la génération à la volée ne devrait se faire que pour générer une grosse miniature toutes les 5 miniatures par exemple, pas pour générer toutes les miniatures.

Ah ben ça après, c'est à ton thème de gérer ça! C'est pas obligé de faire appel au script de génération systématiquement dans le template! Mon script peut aussi très facilement vérifier la taille de la miniature originale, et envoyer le fichier tel quel si celui-ci est égal à la taille demandée par exemple (c'est l'avantage de récupérer les infos directement avec une requête sql!)

flop25 a écrit:

Je testerai la méthode webservice, en même temps que l'ajout d'info tpl pour les albums

Ce n'est pas un webservice, comme je le disais, un webservice peut être ajouté uniquement en plugin.

flop25 a écrit:

Sinon le cache sera géré par smarty alors ? comment fera-t-il pour connaitre si l'image a été modifiée à part en vérifiant les images

Non non, smarty ne gère rien du tout dans cette histoire!
Normalement, une image n'a pas à être modifiée, non?

flop25 a écrit:

Tu n'as toujours pas compris : les gens aiment afficher des grosses miniatures avec genre 250x250. Or ce n'est plus vraiment des miniatures. Si on veut afficher une vraie miniature 120x120 pour un plugin, la page des commentaires au autres ..., il faut charger la 250 pixels ! Ou si l'on veut des images format paysage allongée/croppée pour le thème, mais pas pour le reste .... enfin tu comprends là ?

Si si, j'ai bien compris... c'est pour ça que le code que je t'ai donné met la miniature en cache avec l'id de la photo ET la taille de la miniature... il peut donc y avoir en cache plusieurs fichiers de taille différente pour une même miniature.

flop25 a écrit:

P@t a écrit:

Normalement, une image n'a pas à être modifiée, non?

oula ! faut avoir l'esprit large ! Maintenant les gens veulent modifier leurs image sen ligne : appliquer une rotation, un redimensionnement, rognage un filtre de couleur etc
Donc en fait l'image est générée par le script php à chaque fois ! donc pas très bien non plus

Dans ce cas, il suffit de vérifier la date du fichier en cache avec la date de la websize, pas compliqué...

flop25 a écrit:

mais en terme de performance, la génération à la volée ne devrait se faire que pour générer une grosse miniature toutes les 5 miniatures par exemple, pas pour générer toutes les miniatures.

C'est juste conceptuel : génération à la volée uniquement ponctuelle, génération apriori (gestion par lot/pendant l'upload) pour ce qui doit s’afficher en permanence

Oui, c'est vrai que ce serait bien mieux... pourquoi pas pour la 2.4 pouvoir gérer 3 ou 4 tailles de miniatures différentes...

@gotcha on dévie du sujet mais cela concerne potentiellement tout le monde : ce serait plus une avancée pour les dev Regardez donc comment font d'autres. par ex WordPress crée à l'upload plusieurs tailles d'images selon ce que demande le thème : du coup on a des images en différent format selon les usages Après piwigo gère bien plus d'images ^^ Donc faudra voir en temps voulu ce qu'il est possible de faire, les ressources que ça demande etc

Dernière modification par flop25 (2011-11-08 18:24:35)

il est certainement trop lourd pour Free : parfois ça arrive. Il n'y pas de problème car je l'ai téléchargé depuis ma propre galerie, il y a qq jours sans problème.
Utilisez votre Ftp