BoyWiki:Agora/15 décembre 2010

Agora/15 décembre 2010

Images sur un serveur httpS

J'ouvre un nouveau sujet pour ce problème quand-même assez grave, et qui rend BoyWiki moins attractif pour les lecteurs lambda : sans une intervention particulière de l'utilisateur, les images ne s'affichent pas car situées sur un serveur httpS dont la certification n'est pas reconnue.

Exemple : sur un Firefox vierge de toute navigation sur BoyWiki, le bandeau de la page d'accueil ainsi que l'image du jour ne s'affichent tout simplement pas.

Ensuite on s'étonne que personne ne contribue à BoyWiki. De temps en temps on voit sur la page des modifications récentes des inscriptions de nouveaux utilisateurs, mais aucune activité de leur part : sans doute, ils pensaient qu'en s'inscrivant ils verraient les images...

Bref ce problème est à résoudre en priorité ABSOLUE ! Lascar 15 décembre 2010 à 22:51 (GMT)

Rechercher pourquoi nous manquons de collaborateurs est certes un sujet qui mérite toute notre réflexion (à noter cependant que ça ne semble pas beaucoup plus actif du côté anglais ou allemand). Le problème que tu évoques peut en effet avoir un rôle dans cette pénurie.

Mon navigateur habituel (Opera) n'étant pas vierge (comme bien des choses chez moi), je ne suis pas en mesure de constater cette absence d'images. Certes, il a parfois des difficultés à charger toutes les images d'une page, mais j'attribue plutôt ça au fonctionnement aléatoire de TOR – il suffit généralement de relancer le chargement de la page pour que tout rentre dans l'ordre.

La raison d'être du https pour les images me semble être celle-ci : préserver l'anonymat 1°) de l'administrateur qui envoie une nouvelle image, 2°) de l'utilisateur enregistré qui utilise cette image. Un observateur peut à la rigueur savoir qui est connecté à BoyWiki, mais pas ce qu'il y fait ; alors qu'avec une connexion non sécurisée, il est plus facile de faire le lien entre une activité (donc un pseudonyme) et une IP.

Ceci dit, je ne suis pas informaticien, et ce que je viens d'écrire est peut-être complètement faux ! Je laisse donc la parole à Pinocchio, qui s'y connaît manifestement mieux que moi...

Caprineus 16 décembre 2010 à 02:02 (GMT)

Le problème peut se décomposer :

• Boywiki n'est pas certifié et ne le sera pas j'imagine. Cette certification est nécessaire quand on utilise https, la réaction des navigateurs est donc normale, même s'ils ne réagissent pas tous pareil.
• Le problème apparait même si on se connecte en mode non sécurisé : les adresses des images étant systématiquement notées en https dans les pages. C'est un problème de configuration du serveur et aucun de nous je pense n'a les droits pour le modifier. Il est peut-être possible de changer les adresses à la volée au moment du chargement des pages, mais rien ne garantit que quelques erreurs ne persistent pas (je n'ai pas fait de test), un script n'étant activé que lorsque la page a fini de charger.
• En mode https on ne peut pas en vouloir au navigateur de refuser un contenu qui provient d'un autre serveur : dans ce cas je ne pense pas qu'il soit correct de forcer les images en http (dans la mesure où l'idée de script fonctionnerait), l'utilisateur se croyant protégé.

Dans tout les cas le chargement réussi d'une seule image en https, après avoir accepté le message de mise en garde du navigateur, débloque l'accès à toutes les autres et pour les sessions suivantes. Le plus simple (et possible) serait de prévoir un message explicatif pour le cas de l'utilisateur nouveau ou insuffisamment assidu : mais comment détecter ce cas ?

Pinocchio 16 décembre 2010 à 13:15 (GMT)

Bon, alors concrètement, on fait quoi ? Je trouve ça débile, de placer les images sur un serveur httpS. Qu'y-a-t'il à cacher ? Le nom de l'administrateur qui charge les images ? Mais c'est accessible par la page des modifications récentes de media.boywiki.org... Franchement ce projet BoyWiki marche sur la tête. Rien n'est fait pour garantir un accès simple à l'illustration pour un lecteur lambda...

J'avais pensé rédiger un petit texte en page d'accueil indiquant comment accepter le certificat de Free Spirits (http://freespirits.org/ca/) mais il s'avère que le certificat n'est pas disponible pour BoyWiki. N'importe quoi !

J'espère que tu trouveras une solution correcte. Lascar 16 décembre 2010 à 19:46 (GMT)

Comme je l'expliquais plus haut, je suppose que le https pour les images sert entre autres à éviter qu'un lien puisse être fait entre l'administrateur qui charge une image et son IP. Il ne s'agit donc pas de masquer son pseudonyme (qui est visible sur la page des modifications récentes et sur celle de l'image chargée), mais sa véritable identité (que des autorités mal intentionnées pourraient retrouver grâce à l'IP).

Autrement dit, si « on » peut voir que l'IP 12.345.678.90 charge une image sur BoyWiki, et qu'« on » constate ensuite sur la page de l'image qu'elle a été chargée par un dénommé PseuDoRaste, il sera facile aux intéressés de faire la preuve que l'administrateur de BoyWiki PseuDoRaste s'appelle en réalité Justin Bridou ou Eugène Duschmoll. Ce qui, même s'il n'a rien commis d'illégal, peut être très ennuyeux pour lui...

Si cette hypothèse est exacte, cela pourrait aussi bien se passer pour un contributeur ordinaire, dans le cas où l'accès à BoyWiki ne serait pas sécurisé. Finalement, le https est surtout utile quand on "travaille" sur le wiki, et non pour le consulter. Pour cette dernière utilisation, l'accès pourrait sans doute être en http simple. Mais est-il facile, et pas trop coûteux, de maintenir le wiki sur deux adresses ? Je n'en sais rien.

Encore une fois, cette explication n'est qu'une hypothèse, et en cas d'erreur je ne demande pas mieux que d'être détrompé.

Ceci étant dit, je ne trouve pas que la difficulté pour voir les images soit énorme, même en https. Il suffit de cliquer dans un cadre qui s'affiche de temps en temps (rarement), pour indiquer qu'on accepte le certificat. Les pédérastes ayant un QI insuffisant pour mener à bien cette opération sont sans doute très minoritaires ! :-)

Caprineus 18 décembre 2010 à 18:31 (GMT)

Le comportement diffère selon les navigateurs. En effet, Opéra affiche un cadre parlant de "chaîne du certificat du serveur" incomplète, et de signataires non enregistré. Quelqu'un de prudent cliquera plutôt sur "refuser" et pas sur "accepter". Firefox n'affiche rien du tout, et la place réservée aux images est réduite au néant. Safari affiche un carré bleu avec un point d'interrogation à la place des images. Dans ce dernier cas, il faut penser à cliquer une première fois sur le point d'interrogation, ce qui conduit à la page de description de l'image « Image: ... », dans laquelle il y a un second carré bleu avec un point d'interrogation, ainsi qu'à coté l'image d'un cadenas. En cliquant à nouveau sur l'image du carré bleu, on obtient cette fois un message comme quoi le navigateur " ne parvient pas à vérifier l'identité du site web « media.boywiki.org »". Bref, chaque navigateur a son comportement propre. Bonjour la tartine s'il s'agit de placer une notice explicative sur la page d'accueil adaptée à chaque navigateur...

Lascar 18 décembre 2010 à 22:59 (GMT)

Je ne pensais pas que le problème pouvait être aussi gênant selon les navigateurs ! Merci d'avoir pris la peine de les tester.

Pour l'instant, et jusqu'à preuve du contraire, le https semble quand même utile. Et de toute façon nous n'avons pas les moyens de changer ce type de fonctionnement, qui dépend du tout petit noyau des administrateurs anglophones à l'origine du wiki (même les administrateurs français ont beaucoup de mal à les joindre, apparemment). Il faut donc faire avec.

Ce serait peut-être une bonne chose de mettre sur la page d'accueil un bouton du genre « Si aucune image ne s’affiche sur cette page, cliquez ici pour résoudre le problème ». L'ouverture d'une boîte déroulante permettrait de décrire, pour chaque navigateur, son comportement et la solution à mettre en oeuvre.

Je verrais bien ce bouton soit tout en haut de la page, soit sous la bannière.

Est-ce que tu pourrais essayer de rédiger quelque chose dans ce sens ?

Caprineus 19 décembre 2010 à 14:13 (GMT)