Le contenu de l'article n'est pas accessible tant que le mot de passe n'a pas été saisi, je ne comprend donc pas bien comment les robots peuvent indexer ces articles. Cela se peut t'il qu'ils indexent les fichiers XML des articles directement ?
Est-ce que l'ajout dans les en-têtes des articles protégés par un mot de passe, d'une balise meta robots refusant l'indexation, pourrait aidé ?
Le contenu de l'article n'est pas accessible tant que le mot de passe n'a pas été saisi, je ne comprend donc pas bien comment les robots peuvent indexer ces articles. Cela se peut t'il qu'ils indexent les fichiers XML des articles directement ?
C'est bien la question que je me suis posée mais les faits sont là : Bing et Google référencent certains de mes articles pourtant dans des catégories protégées par mot de passe... :cool:
@joebart : si tu fais référence par exemple à ce lien "http://www.jmr-immobilier.fr/data/documents/0127/PV/PV-AGO-22042013.pdf", tu auras beau mettre un mot de passe sur l'article associé dans PluXml, cela n'en empêchera pas l’accès depuis un moteur de recherche car le lien a déjà été enregistré et est toujours valide.
Tu peux demander un déréférencement en soumettant une requête aux principaux moteurs de recherches mais cela n'est pas assuré de fonctionner sans que tu agisses en premier de ton coté au niveau de ton serveur (d'autant que je n'ai pas trouvé ce lien sur google ou bing mais sur un autre moteur de recherche).
Une solution simple pour déréférencer tes documents sera de casser les liens existants en renommant tous les documents à déréférencer (cela signifie aussi qu'il faudra mettre à jour tes articles avec les nouveaux liens)
Dans un premier temps, il te faut remédier à ce que les futurs documents renommés soient à nouveau indexés (le mieux étant également de les protéger en lecture), sinon tout ce que tu vas faire par la suite ne servira à rien. Ce qui te renvoie aux échanges précédents sur l'usage des fichiers .htaccess (et htpasswd) que tu placeras dans le répertoire "/data/documents/0127/" (ou "/data/documents/" en fonction de ton choix) qui contiendra à minima l'instruction suivante :
Options All -Indexes
Seulement ensuite tu pourras renommer tes documents. Deux possibilités : soit tu renommes chaque document s'il y en a peu (et mets à jour manuellement chaque article), soit tu renommes le répertoire "PV" les contenant si leur nombre est élevé (et tu utiliseras alors la technique du "rechercher/remplacer" pour automatiser la mise à jour des articles associés) (je n'en parle pas plus maintenant car c'est long à expliquer en détail si tu ne connais pas mais cela prends 5 minutes à réaliser)
Dans les deux cas, les liens existant actuellement dans les moteurs de recherche seront cassés.
Puis, pour accélérer leur déréférencement, ajoute (et répète autant de fois qu'il y a de documents à déréférencer) l'instruction suivante au début du fichier .htaccess qui se trouve à la racine de ton site :
Redirect gone "/data/documents/0127/PV/PV-AGO-22042013.pdf"
Redirect gone "/data/documents/0127/PV/PV-AGO-07042010.pdf"
etc.
ou bien cette instruction pour la version avec modification du répertoire :
Redirect gone "/data/documents/0127/PV/"
C'est un peu fastidieux s'il y en a des tonnes, mais c'est le meilleur moyen pour voir ces liens disparaitre des résultats des moteurs de recherche en quelques semaines/mois et assurer à tes clients que leurs documents ne seront plus accessibles par n'importe quel quidam.
Le contenu de l'article n'est pas accessible tant que le mot de passe n'a pas été saisi, je ne comprend donc pas bien comment les robots peuvent indexer ces articles. Cela se peut t'il qu'ils indexent les fichiers XML des articles directement ?
C'est bien la question que je me suis posée mais les faits sont là : Bing et Google référencent certains de mes articles pourtant dans des catégories protégées par mot de passe... :cool:
C'est parce qu'il y a confusion sur le terme "contenu de l'article" et ce qui est réellement référencé par les moteurs de recherche : Joebart fait face à un problème de sécurité au niveau de son serveur web qui laisse accessible à tout le monde des documents qu'il croit avoir protégés.
Les fait sont :
- il a protégé la lecture de l'article avec le plugin -> bien que l'article soit référencé par les moteurs de recherche (via le sitemap) le contenu "textuel" de l'article n'est pas accessible sans mot de passe -> les liens qui sont "contenus" dans l'article ne sont pas accessibles, ni référencés.
- il n'a pas protégé le répertoire contenant les documents qu'il pense avoir protégé -> les moteurs de recherche ne sont pas empêchés de référencer tous les documents contenus dans le répertoire de stockage -> les moteurs de recherche connaissent le lien direct pour accéder à chaque document -> le document est accessible depuis un moteur de recherche.
On notera qu'à chaque fois, c'est le lien direct du document qui est fourni en exemple, et non le lien vers l'article
Conclusion : tant que les répertoires du serveur web ne seront pas protégés, tous les documents resteront référencés et accessibles
Addendum à la conclusion : le référencement d'un article protégé par lockArticles ne pose pas de problème
C'est bien ça Kowalski mais le hic est qu'en effet, j'ai des documents en pdf qu'on va dire "confidentiels" qui sont directement téléchargeables via les liens référencés. Le mot de passe de la catégorie ne remplit pas du coup les conditions pour un verrouillage "total".
a priori les sous dossiers de /data/medias ne sont pas protégés.
on peut lister le contenu, donc il faudrait commencer par protéger avec un simple index.html ou .htaccess.
sinon, faut utiliser un autre outil pour protéger ses documents, un truc comme bozon https://github.com/broncowdd/BoZoN.
ça te permet de gérer tes documents privés d'un coté avec mot de passe si besoin et tout ce qui est public sur pluxml.
C'est bien ça Kowalski mais le hic est qu'en effet, j'ai des documents en pdf qu'on va dire "confidentiels" qui sont directement téléchargeables via les liens référencés. Le mot de passe de la catégorie ne remplit pas du coup les conditions pour un verrouillage "total".
C'est ce que j'essaye de t'expliquer : le mot de passe ajouté par le plugin au niveau des articles ou des catégories ne sert qu'à empêcher l'affichage de ceux-ci depuis PluXml, il ne sert pas à protéger les documents associés aux articles ou catégories.
En essayant de trouver une analogie pas trop bancale : tu as mis une serrure (le plugin) à ta porte (l'article/la catégorie) de ta maison (ton site web sous PluXml). Personne ne peut rentrer dans la maison sans avoir la clé (le mot de passe) de ta porte (l'article/lacatégorie). Sauf qu'une fenêtre est grande ouverte (répertoire mal protégé). Donc tout ce qui se trouve dans la pièce dont la fenêtre est ouverte (tes documents) est visible et directement accessible depuis l'extérieur (le web).
Or ce que tu cherches à faire (protéger l’accès à tes documents clients depuis le web) ne fait pas partie des fonctionnalités offertes par le plugin lockArticles, ni par PluXml (sous le contrôle de Stéphane qui en connait bien mieux le fonctionnement). Si les conseils que nous t'avons donnés sont trop techniques pour toi, je ne peux que t'inviter à te rapprocher d'un professionnel de l'informatique pour résoudre cette situation.
//
autre hypothèse : ton site est actuellement configuré correctement (2016), mais tes fichiers clients ont été référencés avant que tu n'appliques un mot de passe aux articles et catégories (2013 pour notre exemple), ce qui expliquerai qu'ils se retrouvent via les moteurs de recherche
à priori, avec le plugin, l'article n'est pas disponible ni les liens pointant sur tes documents.
pour autant ces documents ne sont pas protégés. on ne connaît pas forcément leur existence ni leur emplacement exact mais on peut essayer d'en déduire l'URL.
si on a l'URL (que l'on a récupéré d'une manière ou d'une autre) rien n’empêche de récupérer le document. il est public.
@sken Personellement je ne rencontre pas de soucis, à 0 les pages s'affichent correctement. Une erreur du serveur ?
C'est-à-dire mettre un mot de passe ? Les articles publiés par les utilisateurs Rédacteur ou Éditeur sont déjà protégés des autres utilisateurs de même types par le mot de passe du compte qui les à publiés. Par contre les comptes administrateurs et gestionnaires peuvent les éditer quoiqu'il arrive afin de modérer les articles publiés par les Rédacteurs et Éditeurs et éventuellement les corriger.
FR/EN MP - Mail - unkorneglosk.fr - Twitter - Je suis modérateur, je dois donc modérater. Ou modérationner. Ou je sais plus. Mais je le fais. En ce moment j'ai des problèmes d'accès à internet je peux mettre du temps à répondre.
en faite sur le site, un visiteur peut se connecter et créer un article, il à juste accès à article.php et l'index.php ,
donc si le visiteur revient pour modifier l'article sans qui est accès au autre article sauf le siens, j'aimerai mettre le mot de passe que lui même choisira.
Ce plugin est ce que je cherchais pour un blog familial. Le mot de passe sur les catégories marche bien. C'est vraiment parfait pour mon usage !
J'ai fait l'erreur de tester le bug de sken en cliquant sur "brouillon (0)" et comme lui j'ai une page blanche : j'ai toujours le menu de pluxml à gauche mais la partie avec la liste des articles devient blanche, sans la liste et les options, y compris en forçant le rafraichissement. Pour avoir de nouveau la liste des articles, je dois me déconnecter/reconnecter. Ce n'est pas très grave, donc, mais je confirme que le bug existe. De mon côté, c'est une installation fraîche de pluxml (5.7), et il n'y a que ce plugin et spxplugindownloader d'activé.
En effet, je n'avais pas très bien compris à la première lecture.
Très étrange. Au niveau du serveur aucune erreur visible ?
FR/EN MP - Mail - unkorneglosk.fr - Twitter - Je suis modérateur, je dois donc modérater. Ou modérationner. Ou je sais plus. Mais je le fais. En ce moment j'ai des problèmes d'accès à internet je peux mettre du temps à répondre.
Réponses
Le contenu de l'article n'est pas accessible tant que le mot de passe n'a pas été saisi, je ne comprend donc pas bien comment les robots peuvent indexer ces articles. Cela se peut t'il qu'ils indexent les fichiers XML des articles directement ?
Est-ce que l'ajout dans les en-têtes des articles protégés par un mot de passe, d'une balise meta robots refusant l'indexation, pourrait aidé ?
C'est bien la question que je me suis posée mais les faits sont là : Bing et Google référencent certains de mes articles pourtant dans des catégories protégées par mot de passe... :cool:
Tu peux demander un déréférencement en soumettant une requête aux principaux moteurs de recherches mais cela n'est pas assuré de fonctionner sans que tu agisses en premier de ton coté au niveau de ton serveur (d'autant que je n'ai pas trouvé ce lien sur google ou bing mais sur un autre moteur de recherche).
Une solution simple pour déréférencer tes documents sera de casser les liens existants en renommant tous les documents à déréférencer (cela signifie aussi qu'il faudra mettre à jour tes articles avec les nouveaux liens)
Dans un premier temps, il te faut remédier à ce que les futurs documents renommés soient à nouveau indexés (le mieux étant également de les protéger en lecture), sinon tout ce que tu vas faire par la suite ne servira à rien. Ce qui te renvoie aux échanges précédents sur l'usage des fichiers .htaccess (et htpasswd) que tu placeras dans le répertoire "/data/documents/0127/" (ou "/data/documents/" en fonction de ton choix) qui contiendra à minima l'instruction suivante :
Options All -Indexes
Seulement ensuite tu pourras renommer tes documents. Deux possibilités : soit tu renommes chaque document s'il y en a peu (et mets à jour manuellement chaque article), soit tu renommes le répertoire "PV" les contenant si leur nombre est élevé (et tu utiliseras alors la technique du "rechercher/remplacer" pour automatiser la mise à jour des articles associés) (je n'en parle pas plus maintenant car c'est long à expliquer en détail si tu ne connais pas mais cela prends 5 minutes à réaliser)
Dans les deux cas, les liens existant actuellement dans les moteurs de recherche seront cassés.
Puis, pour accélérer leur déréférencement, ajoute (et répète autant de fois qu'il y a de documents à déréférencer) l'instruction suivante au début du fichier .htaccess qui se trouve à la racine de ton site :
Redirect gone "/data/documents/0127/PV/PV-AGO-22042013.pdf"
Redirect gone "/data/documents/0127/PV/PV-AGO-07042010.pdf"
etc.
ou bien cette instruction pour la version avec modification du répertoire :
Redirect gone "/data/documents/0127/PV/"
C'est un peu fastidieux s'il y en a des tonnes, mais c'est le meilleur moyen pour voir ces liens disparaitre des résultats des moteurs de recherche en quelques semaines/mois et assurer à tes clients que leurs documents ne seront plus accessibles par n'importe quel quidam.
C'est parce qu'il y a confusion sur le terme "contenu de l'article" et ce qui est réellement référencé par les moteurs de recherche : Joebart fait face à un problème de sécurité au niveau de son serveur web qui laisse accessible à tout le monde des documents qu'il croit avoir protégés.
Les fait sont :
- il a protégé la lecture de l'article avec le plugin -> bien que l'article soit référencé par les moteurs de recherche (via le sitemap) le contenu "textuel" de l'article n'est pas accessible sans mot de passe -> les liens qui sont "contenus" dans l'article ne sont pas accessibles, ni référencés.
- il n'a pas protégé le répertoire contenant les documents qu'il pense avoir protégé -> les moteurs de recherche ne sont pas empêchés de référencer tous les documents contenus dans le répertoire de stockage -> les moteurs de recherche connaissent le lien direct pour accéder à chaque document -> le document est accessible depuis un moteur de recherche.
On notera qu'à chaque fois, c'est le lien direct du document qui est fourni en exemple, et non le lien vers l'article
Conclusion : tant que les répertoires du serveur web ne seront pas protégés, tous les documents resteront référencés et accessibles
Addendum à la conclusion : le référencement d'un article protégé par lockArticles ne pose pas de problème
on peut lister le contenu, donc il faudrait commencer par protéger avec un simple index.html ou .htaccess.
sinon, faut utiliser un autre outil pour protéger ses documents, un truc comme bozon https://github.com/broncowdd/BoZoN.
ça te permet de gérer tes documents privés d'un coté avec mot de passe si besoin et tout ce qui est public sur pluxml.
C'est ce que j'essaye de t'expliquer : le mot de passe ajouté par le plugin au niveau des articles ou des catégories ne sert qu'à empêcher l'affichage de ceux-ci depuis PluXml, il ne sert pas à protéger les documents associés aux articles ou catégories.
En essayant de trouver une analogie pas trop bancale : tu as mis une serrure (le plugin) à ta porte (l'article/la catégorie) de ta maison (ton site web sous PluXml). Personne ne peut rentrer dans la maison sans avoir la clé (le mot de passe) de ta porte (l'article/lacatégorie). Sauf qu'une fenêtre est grande ouverte (répertoire mal protégé). Donc tout ce qui se trouve dans la pièce dont la fenêtre est ouverte (tes documents) est visible et directement accessible depuis l'extérieur (le web).
Or ce que tu cherches à faire (protéger l’accès à tes documents clients depuis le web) ne fait pas partie des fonctionnalités offertes par le plugin lockArticles, ni par PluXml (sous le contrôle de Stéphane qui en connait bien mieux le fonctionnement). Si les conseils que nous t'avons donnés sont trop techniques pour toi, je ne peux que t'inviter à te rapprocher d'un professionnel de l'informatique pour résoudre cette situation.
//
autre hypothèse : ton site est actuellement configuré correctement (2016), mais tes fichiers clients ont été référencés avant que tu n'appliques un mot de passe aux articles et catégories (2013 pour notre exemple), ce qui expliquerai qu'ils se retrouvent via les moteurs de recherche
pour autant ces documents ne sont pas protégés. on ne connaît pas forcément leur existence ni leur emplacement exact mais on peut essayer d'en déduire l'URL.
si on a l'URL (que l'on a récupéré d'une manière ou d'une autre) rien n’empêche de récupérer le document. il est public.
Bonjour à tous,
je suis sur 5.7 et il y a un bug.
quand il est activé et que vous cliquez sur
Brouillons (0) En attente de validation (0)
ça fait une page blanche.
Seulement quand il y a le chiffre 0
et j'aimerai aussi justement qu'on puisse mettre un mot de passe pour pouvoir y accéder à l'article avant de l'éditer. j'ai un projet en tête.
Merci ;)
@sken Personellement je ne rencontre pas de soucis, à 0 les pages s'affichent correctement. Une erreur du serveur ?
C'est-à-dire mettre un mot de passe ? Les articles publiés par les utilisateurs Rédacteur ou Éditeur sont déjà protégés des autres utilisateurs de même types par le mot de passe du compte qui les à publiés. Par contre les comptes administrateurs et gestionnaires peuvent les éditer quoiqu'il arrive afin de modérer les articles publiés par les Rédacteurs et Éditeurs et éventuellement les corriger.
FR/EN MP - Mail - unkorneglosk.fr - Twitter - Je suis modérateur, je dois donc modérater. Ou modérationner. Ou je sais plus. Mais je le fais. En ce moment j'ai des problèmes d'accès à internet je peux mettre du temps à répondre.
pour le bug c'est pas très grave..
en faite sur le site, un visiteur peut se connecter et créer un article, il à juste accès à article.php et l'index.php ,
donc si le visiteur revient pour modifier l'article sans qui est accès au autre article sauf le siens, j'aimerai mettre le mot de passe que lui même choisira.
Avant tout : merciiiiii 😍
Ce plugin est ce que je cherchais pour un blog familial. Le mot de passe sur les catégories marche bien. C'est vraiment parfait pour mon usage !
J'ai fait l'erreur de tester le bug de sken en cliquant sur "brouillon (0)" et comme lui j'ai une page blanche : j'ai toujours le menu de pluxml à gauche mais la partie avec la liste des articles devient blanche, sans la liste et les options, y compris en forçant le rafraichissement. Pour avoir de nouveau la liste des articles, je dois me déconnecter/reconnecter. Ce n'est pas très grave, donc, mais je confirme que le bug existe. De mon côté, c'est une installation fraîche de pluxml (5.7), et il n'y a que ce plugin et spxplugindownloader d'activé.
En effet, je n'avais pas très bien compris à la première lecture.
Très étrange. Au niveau du serveur aucune erreur visible ?
FR/EN MP - Mail - unkorneglosk.fr - Twitter - Je suis modérateur, je dois donc modérater. Ou modérationner. Ou je sais plus. Mais je le fais. En ce moment j'ai des problèmes d'accès à internet je peux mettre du temps à répondre.