La protection des documents téléchargés est à présent immédiate: dès que l'on change le
mode de protection, les fichiers .htacces sont créés/détruis dans tous les sous-répertoires de documents de IMG.
Incidemment, l'option de création des fichiers .htpasswd est à nouveau disponible.
La protection des documents téléchargés est à présent immédiate: dès que l'on change le
mode de protection, les fichiers .htacces sont créés/détruis dans tous les sous-répertoires de documents de IMG.
Une question: est-ce que cette nouvelle option est utilisable d'une façon ou d'une autre pour protéger des documents par #LOGIN_PUBLIC?
Voire même, d'interdire le téléchargement direct sans referer (ou avec
referer venant d'un autre site) (anti leech !)
Le champ Referer n'est pas obligatoire dans le protocole HTTP, merci de
ne pas jouer avec ça. De toute façon on ne voit pas bien l'intérêt d'une
telle protection.
Généralement, c'est pour éviter le "vol" de bande passante par lien direct
sur un fichier depuis un autre site web.
Je viens de comprendre l'histoire des referers !
je suis un peu long à la détente, mais pour des histoires de bande passante,
je comprend mieux la problematique.
Dans ce cas, amha, le mieux est de poser un cookies pour les visiteur
"anonymes" et de tester sa presence à l'affichage du doc.
Ca ne l'empeche pas d'y acceder en direct, mais au moins, tu es sur qu'il
est passé pas ton site avant, dans la meme session.
Il n'y a malheureusement pas de solution idéale, ou alors il faut entrer
dans le genre d'usine à gaz qu'utilisent les portails avec generation d'une
clé sur les liens vers documents.
De cette facon, seul un lien généré par le site peu mener au document, mais
ca implique de gerer la durée de vie de ces clés d'accès et de les stocker.
Sauf cas ultra particulier, je ne vois pas trop l'interet de la chose
La protection des documents téléchargés est à présent immédiate: dès que l'on change le
mode de protection, les fichiers .htacces sont créés/détruis dans tous les sous-répertoires de documents de IMG.
Incidemment, l'option de création des fichiers .htpasswd est à nouveau disponible.
Emmanuel
A propos de .htaccess, serait-il possible de lire la chaine ".htaccess" depuis une variable définie en un endroit unique. Je suis chez un hébergeur qui a choisi de configurer apache pour utiliser "htaccess.fi" au lieu de ".htaccess".
Si la chaine était définie en un seul point (en meta?) il serait plus aisé à ceux qui sont dans mon cas de faire la modif.
Bon, c'était seulement le htaccess du mode protégé qui avait pb, tout semble ok maintenant,
mais je suis tout à fait d'accord sur le fait de donner des noms de fichiers qui ne se différencient pas seulement par leur répertoire.
Yves, j'en ai profité pour crée une constante _ACCES_FILE_NAME dans inc_version, initialisée à .htacces, modifiable à volonté.
Ca vaut aussi pour les occurrences supplémentaires repérées, mais celles-ci ne concernent pas les documents (c'est la protection de ecrire par htpasswd).
En effet, la seule manière de changer cette constante est d'éditer le fichier inc_version, avec le risque d'oublier de le rééditer quand on installe une nouvelle version.
Je pense que l'idéal serait de pouvoir définir ce nom de fichier (et au passage, j'ai oublié ".htpasswd" qui devient htpasswd.fi" chez mon hébergeur) dans le fichier "mes_options". Je ne sais pas si cela ne serait pas trop tard et si le nom .htaccess n'est pas utilisé avant que ce fichier soit chargé.
Cordialement
Yves Grenier
P.S. pour htpasswd, il apparait uniquement (hors commentaires) dans inc_acces (ligne 90). Le redéfinir n'aurait de seul intérêt que de le déplacer en un endroit indépendant de la version installée.
NON.
Ca a déjà fait l'objet d'une discussion sur cette liste:
mes_options est inclus dans inc_version AVANT que celui-ci ne définisse les constantes.
Partant, puisque "les constantes ne peuvent être redéfinies" les définitions dans inc_version seront inopérantes, et c'est bien ce qu'on veut.
Ca peut sembler tordu, mais à coté des centaines de variables non définies dans le code de Spip
(qui du coup déclenchent l'appel du handler quand on veut le redéfinir pour d'autres raisons)
ça m'a paru une goutte d'eau dans la mer du laxisme, et la solution d'Arnaud d'introduire un define_once élimine même cette dernière contrariété.
En effet, la seule manière de changer cette constante est d'éditer le
fichier inc_version, avec le risque d'oublier de le rééditer quand on
installe une nouvelle version.
NON.
Ca a déjà fait l'objet d'une discussion sur cette liste:
mes_options est inclus dans inc_version AVANT que celui-ci ne définisse les constantes.
Partant, puisque "les constantes ne peuvent être redéfinies" les définitions dans inc_version seront inopérantes, et c'est bien ce qu'on veut.
OK, je comprends mieux. J'ajouterai même: je suis content!
Ca peut sembler tordu, mais à coté des centaines de variables non définies dans le code de Spip
(qui du coup déclenchent l'appel du handler quand on veut le redéfinir pour d'autres raisons)
ça m'a paru une goutte d'eau dans la mer du laxisme, et la solution d'Arnaud d'introduire un define_once élimine même cette dernière contrariété.
Emmanuel
Effectivement, ce define_once est super. Je n'avais pas saisi le lien entre les deux problèmes. J'aurais dû avoir la curiosité de regarder le code de inc_version après le post d'ARNO*!