🌍
Français
+20
+100
Ca devient totalement hors-sujet et c'est bien dommage car le sujet est important... merci de reprendre le topic:15938 (auquel je viens d'ajouter un post fort intéressant si j'ose dire)
Disons que ça fait encore une option et une notion en plus à assimiler ...
"Oui" sur le fond de ne pas imposer un tel choix.
Par contre, si on arrivait à conjuguer sécurité et traçabilité ça n'en serait que mieux :-)
Gotcha a écrit:
C'est je crois l'unique raison : la sécurité !
Il devient impossible à un aspirateur de site de pouvoir récupérer toutes les photos en se basant sur la nom du fichier.
Donc c'est peut-être le seul avantage mais des moindres ;-)
Je pense que la moindre des choses serait de laisser le choix à l'utilisateur : lui imposer cette méthode de sécurisation au détriment de la perte du nom de ses photos ne me paraît pas une bonne solution.
My own 0.02.
tosca a écrit:
Pourrait-on reprendre un peu de "hauteur de vue" et exprimer quels sont les avantages du renommage des photos (je ne suis pas sûre d'avoir bien tout saisi ... suis-je la seule ?) En dehors du fait que le visiteur ne peut "deviner" le nom des photos, quels sont les autres avantages reconnus / recherchés ?
C'est je crois l'unique raison : la sécurité !
Il devient impossible à un aspirateur de site de pouvoir récupérer toutes les photos en se basant sur la nom du fichier.
Donc c'est peut-être le seul avantage mais des moindres ;-)
vimages a écrit:
Oui, ça m'intéresse aussi....
Le maintient des noms originaux des photos est trop important pour ne pas suivre le sujet.
Je ne peux concevoir qu'un fichier, après avoir été téléchargé sur l'ordinateur d'un visiteur, ait un autre nom que celui que je lui aurais moi-même attribué avant sa mise en ligne.
Je te suis tout à fait sur le sujet (Cf. post:130459)
vimages a écrit:
Désolé.. je sais que mon avis n'est pas celui du team, mais c'est celui d'un utilisateur averti des enjeux sécuritaires , et faisant face aux réalités du terrain.
Je ne pense pas que la team ait un avis sur le sujet ; je revendique en tout cas d'avoir mon propre avis sur le sujet, qui est que l'on doit pouvoir assurer la traçabilité de bout en bout, de l'amont vers l'aval et vice-versa, incluant les éventuels "sous-produits" tels que vignettes, images HD, verso, etc.
VDigital a écrit:
Encore une fois, il ne peut pas y avoir maintien du nom du fichier d'origine mais seulement une "piste d'Audit" (pour ceux qui ne comprennent pas ce que cela signifie (je sais que tosca comprends parfaitement)
Veux-tu dire : il peut ne pas y avoir ... auquel cas je suis d'accord sur le principe ; mais c'est tout de même beaucoup moins confortable pour l'utilisateur qu'une lecture directe.
Pourrait-on reprendre un peu de "hauteur de vue" et exprimer quels sont les avantages du renommage des photos (je ne suis pas sûre d'avoir bien tout saisi ... suis-je la seule ?) En dehors du fait que le visiteur ne peut "deviner" le nom des photos, quels sont les autres avantages reconnus / recherchés ?
Serait-il concevable qu'un même pLoader offre les deux options : avec ou sans renommage, selon le souhait de l'utilisateur (le webmaster de la galerie en l'occurence).
Vous avez vérifier ce que pLoader faisait à ce sujet ?
Remarquez : moi non plus je n'ai pas regardé :-$
Gotcha a écrit:
Slimane a écrit:
Qu'en pensez vous ?
Je crois que pLoader concatène déjà le nom original + une chaîne aléatoire (à confirmer).
La récupération du nom d'origine à mon avis c'est bien là qu'est la difficulté.
et ouui.. c'est là le problème !
sur la suggestion de Slimane, il est de mon avis de mettre les caractères aléatoires en fin de nom de fichier, car, le choix de mettre au début, par exemple, la date à l'américaine, suivie de différentes information, permet de trier et retrouver très facilement le fichier dans une liste.
Slimane a écrit:
Qu'en pensez vous ?
Je crois que pLoader concatène déjà le nom original + une chaîne aléatoire (à confirmer).
La récupération du nom d'origine à mon avis c'est bien là qu'est la difficulté.
J'ajouterai, si la chaine aléatoire doit être maintenue, qu'est ce qui empêche de concaténer cette chaine et le nom d'origine, la sécurité serait maintenue et il serait possible d'identifier le lieu + mots clés éventuels + le crédit (très important lorsqu'on met à disposition des photos !.
Pour les bases déjà en place, il serait possible de cocher une case afin d'utiliser ou non ce nommage pour les prochains upload.
Ainsi on obtiendrai bf23edf214c58-place-erlon-credit-jp-dupont.jpg (après tout nous avons de la marge pour la longueur des noms).
Vu que je met des photos à disposition au quotidien et à des journalistes par ex, il est primordiale d'avoir l'identité dans le nom de fichier, c'est productif !!! n'est ce pas le but d'une telle application...
La seconde solution serait peut-être de pouvoir générer un zip qui reprenne le titre d'origine, mais je pense que c'est beaucoup plus compliquer à mettre en place (download multi).
Qu'en pensez vous ?
L'ajout de la chaine aléatoire à était faite dans un sens. Donc il doit bien être possible de faire la chose inverse non ?
La problème ça va être : Quand faire cette machine arrière ?
Il existe plusieurs façons de récupérer une photo propulsée par Piwigo. C'est à mon avis là qu'il faut bucher.
Encore une fois, il ne peut pas y avoir maintien du nom du fichier d'origine mais seulement une "piste d'Audit" (pour ceux qui ne comprennent pas ce que cela signifie (je sais que tosca comprends parfaitement), on peut parler d'un fin d'Ariane qui permet de retrouver ses petits).
je ne suis pas à l'origine de l'implémentation des Web services Piwigo et du choix de conception qui attribue automatiquement un nom au fichier uploadé. Je peux donc donner un point de vue relativement objectif sur la question.
La façon de nommer les fichiers n'est qu'une convention de codage. Celle qui est utilisée par l'API permet de générer des noms uniques sans intervention humaine, en se basant sur le contenu binaire du fichiers. Ainsi, deux photos différentes uploadées successivement mais portant le même nom de fichier ( IMG_005.JPG par exemple ), sont identifiés différemment, sans risque d'écrasement.
Les utilisateurs qui nomment leurs fichiers à partir de la date, de l'auteur, du destinataire, d'un chrono et de tout autre critère de leur choix ne font qu' appliquer une convention de nommage. Sont ils pour autant sûrs que les noms générés seront uniques ? Le niveau d'automatisme qu'ils vont utiliser pour nommer leurs fichiers va t-il garantir que cette convention sera systématiquement appliquée, et sur les bons fichiers ?
Le mode de fonctionnement FTP + catégories physiques laisse une grande liberté d'organisation de son arborescence de fichiers et dans ce mode de fonctionnement, le nom du fichier a naturellement une place importante.
Les utilisateurs qui utilisent ce sytème de longue date et qui en sont satisfaits n'ont pas de raison d'utiliser pLoader. Ils seront forcément frustrés car les choix d'organisation retenus sont différents.
Maintenant je ne suis par sûr que nommer ses fichiers à la main ou avec un script dont on change les paramètres soit plus sûr que de se baser sur le contenu binaire du fichier pour l'identifier.
Oui, ça m'intéresse aussi....
Le maintient des noms originaux des photos est trop important pour ne pas suivre le sujet.
Je ne peux concevoir qu'un fichier, après avoir été téléchargé sur l'ordinateur d'un visiteur, ait un autre nom que celui que je lui aurais moi-même attribué avant sa mise en ligne.
Désolé.. je sais que mon avis n'est pas celui du team, mais c'est celui d'un utilisateur averti des enjeux sécuritaires , et faisant face aux réalités du terrain.
Les fichiers physiquement contenus dans la galerie, les noms affichés sur les pages thumbnail et photo et affichés dans les métadatas, doivent absolument être les noms d'origines des fichiers.
Seuls, les noms apparaissant dans une URL peuvent être différents, car non utilisés par le visiteurs lambda.
...... :o)
merciiii
éric.
VDigital a écrit:
Les détracteurs (des noms des images actuellement générés) découvriront certainement dans quelques temps la solution assurant la "piste d'audit" des images.
VDigital a écrit:
Sauf que je n'ai jamais écrit que la prochaine version contiendrait une solution assurant la "piste d'audit" des images.
Mais pour en avoir évoqué le problème la semaine dernière, je sais que cela viendra.
Du nouveau sur le sujet ?