J'ai posé la question a Free.fr bien sûr comme N personnes avant moi ...
Ils m'ont répondu que cela marché en utilisant "Multiview" ... j'en ai déduit qu'il voulait parlait du module apache multiview ...
Question :
1/ est-ce bien le module d'apache ? Je pense que oui ...
2/ Théoriquement ce mod est activé sur les serveurs de free ..., il y a t-il un moyen d'obtenir les info de config d'apache (script php ou autre) pour vérifier ?
3/ J'ai bien essayé ton script VDigital en mettant l'option +Mulviview, mais pas mieux. Ne faut-il pas l'adapter ?
Merci.
VDigital a écrit:
et que l'hébergeur l'autorise (même free l'autorise, je crois).
Ben non!
Désolé.
8-)
Alors j'ai essayé en remplaçant "http://www.myparent.org/" par l'url de mon site.
Ben chez free, çà n'a pas l'air de marché par ce que dés que je met le .htaccess en place, j'ai plus d'image.
Il semblerait que le RewriteEngine soit désactivé chez free.
Pensée du soir : Pourquoi faut il que chaque fois qu'il y a un truc qui marche pas cela soit chez free ... bouh ....
En plein désespoir j'ai bien tenté ceci :
SetEnvIfNoCase Referer "^http://www.votre-domaine.com/" locally_linked=1
SetEnvIfNoCase Referer "^http://www.votre-domaine.com$" locally_linked=1
SetEnvIfNoCase Referer "^http://votre-domaine.com/" locally_linked=1
SetEnvIfNoCase Referer "^http://votre-domaine.com$" locally_linked=1
SetEnvIfNoCase Referer "^http://www.un-autre-domaine.com/" locally_linked=1
SetEnvIfNoCase Referer "^http://www.un-autre-domaine.com$" locally_linked=1
SetEnvIfNoCase Referer "^$" locally_linked=1
<FilesMatch "\.(gif|png|jpe?g)$">
Order Allow,Deny
Allow from env=locally_linked
</FilesMatch>
trouvé sur le net mais marche pas non plus.
Merci beaucoup quand même en tout cas.
Non, ce n'est pas plus compliqué. Si ton hébergement est apache et que l'hébergeur l'autorise (même free l'autorise, je crois).
#
#.htaccess in ./distant/ main directory
#
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://www.myparent.org/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://myparent.org/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.mypartner.org/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://mypartner.org/.*$ [NC]
RewriteRule .*\.*$ /copyright.jpg [NC]
Ne pas oublier de créer le fichier copyright.jpg qui fera bien plaisir aux hotlinks.
8-)
Je relance le sujet.
Etant novice dans le domaine PHP/SQL/HTML, je voudrais savoir comment peut-on interdire l'accès direct aux images stockées sur un site distant, tout en utilisant la fonctionnalité du "site distant" de PWG. Suffit il de mettre un .htaccess avec des paramètres ou est-ce plus compliqué ?
merci.
Moins j'utilise la un.. à la babarbe...
Mais, ce qu'il faut ne pas oublier c'est de supprimer le fichier XML car même si on ne peut pas le générer si la dernière version est encore là...
Donc une bonne solution serait d'empecher l'execution et de supprimer le fichier XML au bon moment!
Il existe plusieurs solutions envisageables pour sécuriser l'emploi du create_listing_file.php.
La première, vous l'avez dit, est de le renommer. Cela fonctionne sans problème si on appelle le script directement, sans passer par le(s) site(s) principal(aux).
La seconde consiste à ce que l'appelant du script (navigateur ou site principal) s'authentifie auprès du site distant. Cette solution est trop lourde.
La troisième consiste à paramétrer un identifiant/mot de passe dans le script et à les demander à chaque opération (générer, tester ou supprimer). Cette méthode est simple, efficace, maintenable, facile à documenter... En bref c'est celle que je préconise.
Il existe des solutions plus "secure" mais elles passent par des htaccess complexes.
Je peux coder la troisième si vous êtes intéressés.
C'était déjà clair...
On reformule:
Un site distant va servir d'entrepôt d'images pour plusieurs sites de présentation. (SD: sd.org).
Un site accèdant à SD (SP: sp.com).
Un autre (SN: sn.net).
SP pourrait être en 1.6 et SN en 1.7
il faut pourtant qu'ils utilisent SD tous les deux.
Pour couronner le tout, SD n'est pas publique, un .htaccess fera (peut-être) bien le filtrage mais...
create_listing_file.php étant unique actuellement, il ne permet pas le partage entre 1.6 et 1.7.
Il faudrait avoir un create_listing_file.php (avec un nom spécifique) par site de présentation.
Laurent ? Jouable ?
8-)
Services Web ... utilisateurs experts
Ce que j'imagine est un dépôt de photos qui serait partagé par deux sites distincts.
Le paramétrage des noms permettrait alors de faire ceci :
- le site pwg1 obtient la liste list1 à l'aide du script clf1 déposé sur le partage
- le site pwg2 obtient la liste list2 à l'aide du script clf2 déposé au même endroit
Chaque site exploite les photos à sa manière.
Concernant l'identité des versions :
- pwg1 == clf1
- pwg2 == clf2
Mais on peut avoir clf1 != clf2.
J'espère avoir été plus clair.
Fildefr
Partage... Services Web.
"Et pourquoi pas paramétrer le nom de ces deux fichiers ?"
Oui... C'est sans doute ce qu'il faut faire.
"sans imposer les contraintes actuelles comme l'identité des versions" : C'est indispensable sinon on risque de faire des bêtises.
8-)
Merci pour le conseil.
Cela fonctionne mais nécessite de repasser par ftp : la fonction Nettoyer est donc inutile.
Et si l'on plaçait create_listing_file.php et listing.xml dans un autre répertoire que la racine des photos ?
Cela permettrait de protéger ce répertoire sensible tout en laissant libre l'accès individuel aux photos.
Et pourquoi pas paramétrer le nom de ces deux fichiers ?
En plus de l'amélioration de la sécurité, cela permettrait le partage d'un ensemble de photos entre deux sites pwg sans imposer les contraintes actuelles comme l'identité des versions et du paramétrage des deux sites.
Qu'en pensez-vous ?
Fildefr
Une fois la synchro réalisée, je le renomme en tu_ne_sauras_pas_-.asp
8-)
Il est recommandé :
- de protéger les répertoires pour éviter de les lister
- de nettoyer le fichier listing.xml pour éviter de dévoiler la liste des photos
Mais à quoi cela sert si on laisse create_listing_file.php que tout le monde peut exécuter ?
Y a-t-il un moyen de limiter cette exécution ?