Journal : Gestionnaire d'images hi-res
Posté par Lol Zimmerli (Jabber id, page perso, ) le 31 août 2005
Cher journal,
Je suis à la recherche d'un logiciel de type 'galerie de photos en php' mais avec lequel un clic sur une vignette provoquerait le téléchargement (save as box) de l'image hi-res (des jpeg rgb en 3, 4 et 5 mégapixels) en lieu et place de la traditionnelle page avec l'image en grande taille. Si en plus on pouvait gérer des utilisateurs, alors ce serait le bonheur; sinon, si le produit est libre, je ferai cette partie avec mes petites mains.
As-tu connaissance d'un tel logiciel?
Je suis à la recherche d'un logiciel de type 'galerie de photos en php' mais avec lequel un clic sur une vignette provoquerait le téléchargement (save as box) de l'image hi-res (des jpeg rgb en 3, 4 et 5 mégapixels) en lieu et place de la traditionnelle page avec l'image en grande taille. Si en plus on pouvait gérer des utilisateurs, alors ce serait le bonheur; sinon, si le produit est libre, je ferai cette partie avec mes petites mains.
As-tu connaissance d'un tel logiciel?
> Lire le journal (26 commentaires, moyenne: 1,6).
Vous avez demandé le commentaire #618983.
Run by 
Cette page a été générée par Templeet en 0.0604s (dont 0.0061 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
wagen ?
Bonjour,
J'avais écris il y a quelque temps en PHP un album web de photos.
Il est sous GPL. Actuellement, tu n'as pas le téléchargement de la photo lorsque tu cliques dessus la miniature, mais il n'est pas difficile de l'implémenter.
Par contre il ne gère pas les droits des utilisateurs car il est dédié à une et unique chose (dans l'esprit d'Unix): permettre la consultation d'albums photos. Aussi, gèrer les droits d'utilisateurs seraient plus la tâche d'un autre programme qui donnerait alors l'accès à l'album web.
je dois avouer que c'est un programme simple, donc le code est court et simple. Il s'appuit sur le système de fichiers et non sur une base de données.
Tu peux le trouver ici:
http://miguel.moquillon.free.fr/download/wagen-1.4.5.tar(...)
Sinon, voici un exemple du programme:
http://miguel.moquillon.free.fr/miguel/wagen/index.php(...)
[^]Re: wagen ?
A quoi sert le code Javascript pour cliquer sur les images ?
Quel est l'avantage par rapport à un lien hypertexte qui justifie de perdre l'accessibilité et le confort de l'ouverture dans un nouvel onglet ?
[^]Re: wagen ?
A envoyer un formulaire via un lien hypertexte par la méthode POST (qui est plus sécurisée que GET). Ce formulaire contient l'information demandé par l'utilisateur ainsi qu'un certain contexte.
Mais je reconnais que par ce biais on perd l'avantage de pouvoir ouvrir une page dans un autre onglet ou fenêtre.
[^]Re: wagen ?
J'ai oublié aussi ceci: j'aurais pu passer par une variable de session (qui utilise les cookies) pour enregistrer les informations nécessaires au passage à la page suivante. Ceci aurait effectivement évité d'utiliser du javascript. Toutefois, je ne voulais pas imposé aux utilisateurs l'acceptation de cookies pour simplement visualiser les photos ou parcourir un album. Seule la partie diaporama nécessite ces derniers.
De plus, je pense toutefois que l'on peut parcourir les photos et les albums facilement via les liens proposés et que donc ceci permet de compenser le manque de navigation par onglets ou fenêtres du navigateur.
[^]Re: wagen ?
A envoyer un formulaire via un lien hypertexte par la méthode POST (qui est plus sécurisée que GET).
En quoi la méthode POST serait elle plus sécurisée que GET. J'ai beau chercher, je ne vois pas ?
[^]Re: wagen ?
Simplement sur le fait que le gars qui regarde par dessus ton épaule dans le couloir ne vois pas les paramètres que tu as rentré dans l'url.
Sinon, c'est vrai que y'a pas grand chose qui différe.
[^]Re: wagen ?
Peut être, mais dans le contexte c'est complètement inutile et empeche le visiteur de naviguer comme il veut.
[^]Re: wagen ?
De naviguer comme il veut ? Faut pas exagérer non plus.
Comme je disais plus haut, le système de lien permet toutefois une navigation aisée et la restriction par rapport à une ouverture sur un nouvel onglet ou une nouvelle fenêtre n'est pas si rebutante que cela.
Ca me fait rappeler les arguments des windowsiens qui se plaignent qu'ils n'aient pas par défaut les droits d'administration de leur machine GNU/Linux ! Que la sécurité c'était trop contraignante ... sur leur habitude.
Si il n'y a que cela et si ça t'intéresse, je peux toujours prendre un peu de mon temps pour changer ça et utiliser une méthode GET. Voir, le paramètrer dans un fichier de conf. Mais faut être patient parce que je n'ai pas bcp de temps en ce moment.
[^]Re: wagen ?
A ce que les données transitent dans le corps de la requête HTTP et qu'un utilisateur ne puisse profiter des URL rewriting ou faire passer des données via URL qui coincideraient avec un trou de sécu du serveur HTTP ou de l'environnement PHP.
Bien sûr, aujourd'hui, ce genre de faiblesse est pluto rare.
[^]Re: wagen ?
On peut aussi bien faire transiter les données qu'on veut en formattant une requête avec POST grâce à des softs comme curl ou avec un peu de programmation.
Les trous de sécu sont aussi fréquent en POST qu'en GET, un buffer overflow prut très bien arriver avec des variables transmises via POST ainsi que les SQL injections etc ...
C'est une légende urbaine que de croire que GET est plus sécure que POST.
[^]Re: wagen ?
Mettre les données en POST évite d'afficher dans l'URL numeroCB= xxxxx, ce qui évite qu'en manipulant l'historique d'un navigateur on ait ce genre d'infos. De plus certains proxys conservent les pages appellées avec des paramètres get (ce qu'ils ne devraient pas).
Enfin pour des données vraiement confidentielles, seule la méthode POST convient pour envoyer de l'https puisque les paramètres get ne sont pas cryptés...
Donc dans tous les cas le POST est plus secure que le GET.