Forum ZitePLUS

La communauté des utilisateurs du CMS ZitePLUS

Vous n'êtes pas identifié(e).

#1 03/05/2013 14:37:22

kyodev
Membre
Lieu : Lyon
Inscription : 19/04/2013
Messages : 11

correction view.php

bonjour

2 petits défauts que j'ai été amené à corriger sur Zite+ 0.9.2, fichier view.php

  1. fichier de type non déclaré
    si le type mime n'est pas déclaré  (dans zplus/mime.txt?), le fichier est affiché au lieu d'être proposé en téléchargement

  2. document inexistant
    si on appelle n'importe quoi, par ex: /view.php/fghjkljhg.jpg, on se retrouve avec une page vide et un entete:
    HTTP/1.1 200 OK
    ...
    Content-Type: text/html


1: correction; par défaut envoi entete  application/octet-stream (au lieu de  text/plain)
diff:

[== Indéfini ==]
@@ -24 +24,2 @@
-				$contenttype= isset($mimetype[$doc[cDocExt]])?$mimetype[$doc[cDocExt]]:'text/plain';
+					// force le téléchargement d'un tyoe de fichier inconnu au lieu de l'afficher
+				$contenttype= isset($mimetype[$doc[cDocExt]])?$mimetype[$doc[cDocExt]]:'application/octet-stream';

2: complétion condition négative inexistante
diff:

[== Indéfini ==]
@@ -36,0 +38,3 @@
+		} else {
+				// en cas de document inexistant, envoi erreur 404
+			header($_SERVER['SERVER_PROTOCOL'].' 404 Not Found');

fichier complet view.php visible ici

Hors ligne

#2 05/05/2013 00:40:16

jpg
Administrateurs
Inscription : 19/11/2008
Messages : 2 074
Site Web

Re : correction view.php

Bonsoir,

kyodev a écrit :

1.  fichier de type non déclaré
si le type mime n'est pas déclaré, le fichier est affiché au lieu d'être proposé en téléchargement

Tout à fait, et certains navigateurs (à l'époque ou j'ai fait les tests) sont capables dans ce cas là d'afficher correctement le fichier dans le navigateur.
Mais je comprends ta remarque: j'aurais pu faire le choix inverse.

kyodev a écrit :

2. document inexistant
si on appelle n'importe quoi, par ex: /view.php/fghjkljhg.jpg, on se retrouve avec une page vide et un entete:
HTTP/1.1 200 OK
...
Content-Type: text/html

Une version interne qui renvoyait un code 404 a existé ... le temps du test.
Le fait de ne pas renvoyer d'erreur 404 sur un document inexistant ou inaccessible à certains utilisateurs (car privé) est un choix que j'assume pleinement  wink
Il est ainsi possible d'avoir sur une seule page HTML, des documents (de type image) qui s'affiche ou ne s'affiche pas en fonction de l'utilisateur et cela sans provoquer de disgracieux messages d'erreurs.

a+
Jean-Paul

Hors ligne

#3 05/05/2013 08:06:59

kyodev
Membre
Lieu : Lyon
Inscription : 19/04/2013
Messages : 11

Re : correction view.php

bonjour

jpg a écrit :

certains navigateurs sont capables dans ce cas là d'afficher correctement le fichier dans le navigateur.

humm, ça dépend du type de fichier, dans mon cas, un .kml affiché c'est pas ... esthétique wink
et encore faut-il, si l'appli n'est pas correctement configurée, que le serveur le soit... ça commence à devenir technique pour un utilisateur final (je pense à celui qui devrait faire ou compléter une page).
et puis si la configuration n'est pas courante (pré-configurée), dans mon cas: application/vnd.google-earth.kml+xml .kml, il n'y pas de raison que le navigateur soit capable de gérer, et dans ce cas, c'est à l'utilisateur final de prendre le relais s'il ne veut pas télécharger mais ouvrir dans une appli.

jpg a écrit :

des documents (de type image) qui s'affiche ou ne s'affiche pas en fonction de l'utilisateur

oui, je n'ai pas envisagé le cas des droits. pour les pages, c'est parfait, l'erreur 404 est bien émise, mais dans le cas que j'ai rencontré, pour une image un

header($_SERVER['SERVER_PROTOCOL'].' 404 Not Found');

ne perturbe pas l'affichage, je pense (mais non testé) qu'une erreur 403 ne devrait pas gêner, c'est le navigateur qui décide.

ça permetterait:
.de tester automatiquement un site avec une appli, Xenu par exemple,
.de surveiller le site avec des outils webmaster ou les logs (je logue spécifiquement les erreurs 404 pour suivre les évolutions et pour mettre à jour au besoin un htaccess pour aiguiller les moteurs de recherche ).

de plus un code 200 avec un même contenu (vide) ne doit pas participer à un bon indexage par les moteurs de recherche, de même 403 devrait éviter de maintenir l'indexage d'un document privé.

amha, il faudrait peaufiner alors, 403? si ce n'est déjà fait? ou 404.
mais il n'y a pas que les images, un pdf, participant pour beaucoup à l'indexage, doit absolument renvoyé un 404 à un moteur s'il n'est pas présent.

si ça peut aider à la réflexion...

cordialement

Hors ligne

#4 05/05/2013 12:04:13

jpg
Administrateurs
Inscription : 19/11/2008
Messages : 2 074
Site Web

Re : correction view.php

kyodev a écrit :
jpg a écrit :

certains navigateurs sont capables dans ce cas là d'afficher correctement le fichier dans le navigateur.

humm, ça dépend du type de fichier, dans mon cas, un .kml affiché c'est pas ... esthétique wink

C'est sur wink c'est affiché comme du texte

kyodev a écrit :

et encore faut-il, si l'appli n'est pas correctement configurée, que le serveur le soit... ça commence à devenir technique pour un utilisateur final (je pense à celui qui devrait faire ou compléter une page).
et puis si la configuration n'est pas courante (pré-configurée), dans mon cas: application/vnd.google-earth.kml+xml .kml, il n'y pas de raison que le navigateur soit capable de gérer, et dans ce cas, c'est à l'utilisateur final de prendre le relais s'il ne veut pas télécharger mais ouvrir dans une appli.

Oui, comme je le disais je comprends ta remarque, elle est légitime, je ne dis pas non.
Dans l'immédiat le plus simple pour toi est de rajouter ce type dans mime.txt.

kyodev a écrit :
jpg a écrit :

des documents (de type image) qui s'affiche ou ne s'affiche pas en fonction de l'utilisateur

oui, je n'ai pas envisagé le cas des droits. pour les pages, c'est parfait, l'erreur 404 est bien émise, mais dans le cas que j'ai rencontré, pour une image un

header($_SERVER['SERVER_PROTOCOL'].' 404 Not Found');

ne perturbe pas l'affichage, je pense (mais non testé) qu'une erreur 403 ne devrait pas gêner, c'est le navigateur qui décide.

Les documents, c'est autres choses: rien à voir avec les pages. Ils ont aussi des droits propres (oui, ZitePlus, c'est un tout petit CMS, mais puissant sur les droits wink )
Il faut penser aux documents images insérés dans une balise <img>, et un code d'erreur 404 (ou 403 quand l'image est privé), c'est pas terrible sad

kyodev a écrit :

ça permetterait:
.de tester automatiquement un site avec une appli, Xenu par exemple,
.de surveiller le site avec des outils webmaster ou les logs (je logue spécifiquement les erreurs 404 pour suivre les évolutions et pour mettre à jour au besoin un htaccess pour aiguiller les moteurs de recherche ).

de plus un code 200 avec un même contenu (vide) ne doit pas participer à un bon indexage par les moteurs de recherche, de même 403 devrait éviter de maintenir l'indexage d'un document privé.

Pour l'instant, cela n'a pas semblé être un frein pour l'indexation wink

kyodev a écrit :

amha, il faudrait peaufiner alors, 403? si ce n'est déjà fait? ou 404.
mais il n'y a pas que les images, un pdf, participant pour beaucoup à l'indexage, doit absolument renvoyé un 404 à un moteur s'il n'est pas présent.

si ça peut aider à la réflexion...

ça aide, ça aide wink


a+
Jean-Paul


ps: la version suivante des view.php et thumb.php a déjà été publié il y a quelques semaines dans un autre sujet (pour la 0.9.3 de test), mais elles sont compatible 0.9.2

Hors ligne

#5 05/05/2013 17:55:56

kyodev
Membre
Lieu : Lyon
Inscription : 19/04/2013
Messages : 11

Re : correction view.php

jpg a écrit :

Il faut penser aux documents images insérés dans une balise <img>, et un code d'erreur 404 (ou 403 quand l'image est privé), c'est pas terrible sad

?? je ne sais pas si on se comprend, une image manquante (404) ne dégrade pas une page, si l'attribut alt existe, il est affiché, si pas d'attribut alt, rien n'est affiché. par contre, des appli, des scripts serveur eux peuvent dans ce cas fonctionner.
pour 403, jamais testé, je veux bien le faire mais je présume que pas de problèmes

jpg a écrit :

Pour l'instant, cela n'a pas semblé être un frein pour l'indexation wink

content duplicate?
une erreur ne sera jamais grave, si c'est en nombre, le site n'aura pas sa position optimum. le référencement, c'est pas 1 règle, c'est une somme de détails, qui pour la plupart ne sont que du bon sens.

mais si les choses sont figées, je m'arrête donc là.

Hors ligne

#6 06/05/2013 18:05:14

jpg
Administrateurs
Inscription : 19/11/2008
Messages : 2 074
Site Web

Re : correction view.php

kyodev a écrit :
jpg a écrit :

Il faut penser aux documents images insérés dans une balise <img>, et un code d'erreur 404 (ou 403 quand l'image est privé), c'est pas terrible sad

?? je ne sais pas si on se comprend, une image manquante (404) ne dégrade pas une page, si l'attribut alt existe, il est affiché, si pas d'attribut alt, rien n'est affiché. par contre, des appli, des scripts serveur eux peuvent dans ce cas fonctionner.
pour 403, jamais testé, je veux bien le faire mais je présume que pas de problèmes

jpg a écrit :

Pour l'instant, cela n'a pas semblé être un frein pour l'indexation wink

content duplicate?
une erreur ne sera jamais grave, si c'est en nombre, le site n'aura pas sa position optimum. le référencement, c'est pas 1 règle, c'est une somme de détails, qui pour la plupart ne sont que du bon sens.

content-duplicate ?
Sauf erreur ça apparaît dans google analytics, donc on peut suivre et corriger.
Après, bien sur, il vaut mieux que cela n'arrive pas, comme les erreurs 404 d'ailleurs wink

kyodev a écrit :

mais si les choses sont figées, je m'arrête donc là.

Figées ou pas: la question ne se pose pas en ces termes là.
Mais avant de toucher à un script de base ... je prends toujours des précautions wink

D'autant plus qu' à l'époque ou j'ai fait les tests avec IE et Firefox, il y a des trucs qui ne marchaient pas bien si on renvoyait via php un code d'erreur 404 pour une
image avec par exemple <img src=..../view.php/testimage.png>. Je ne sais plus avec lequel des deux navigateurs, mais vu que c'était les deux qui dominaient sans
partage le marché, je me suis adapté et j'ai retiré la génération de l'erreur 404.

Je n'ai pas re-testé depuis, peut-être que c'est parfaitement géré maintenant.
Je regarderai afin de déterminer ce qu'il en est avec les principaux navigateur du marché aujourd'hui.

a+
Jean-Paul

Hors ligne

#7 12/07/2015 19:03:52

jpg
Administrateurs
Inscription : 19/11/2008
Messages : 2 074
Site Web

Re : correction view.php

jpg a écrit :

D'autant plus qu' à l'époque ou j'ai fait les tests avec IE et Firefox, il y a des trucs qui ne marchaient pas bien si on renvoyait via php un code d'erreur 404 pour une
image avec par exemple <img src=..../view.php/testimage.png>. Je ne sais plus avec lequel des deux navigateurs, mais vu que c'était les deux qui dominaient sans
partage le marché, je me suis adapté et j'ai retiré la génération de l'erreur 404.

Je n'ai pas re-testé depuis, peut-être que c'est parfaitement géré maintenant.
Je regarderai afin de déterminer ce qu'il en est avec les principaux navigateur du marché aujourd'hui.

J'ai pris un peu de temps, mais j'ai re-testé depuis: plus de différence de comportement selon les navigateurs.
Aussi à partir de la version 0.9.5, view et thumb renvoient tous les deux un code d'erreur 403 s'il n'est pas possible d'accéder à l'image pour une raison ou une autre.
Aucune différence n'est faite entre un document inexistant ou des droits inapropriés (inutile de renseigner un éventuel attaquant wink)

a+
Jean-Paul

Hors ligne

Pied de page des forums