Auteur Sujet: Passer le forum sous Discourse ? (Lu 17825 fois)

turold · « **Réponse #12 le:** 11 juin 2016 à 17:35:56 »

Citation de: jack le 11 juin 2016 à 16:49:06

Tu es injuste

Désolé, je pète un peu les plombs.

L'air est lourd par chez moi, et trop peu d'orages, et même pas tout près...

Citation de: jack le 11 juin 2016 à 16:49:06

Prenons la question dans l'autre sens :
- qu'est-ce que vivien va gagner avec ça ?
- qu'est-ce que l'utilisateur va gagner ? Est-ce perceptible ?

En résumé, est-ce que tu vas avoir une révolution, ou plutôt une évolution ?

Http/2, de la rapidité. La sécurité à ce niveau est déjà présente avec http/1.1 over TLS.
PHP7, de la sécurité (entre autres), mais là, après 2018, sur le LTS 14.04, cela va vraiment y poser un problème! En attendant, pas le feu.

Mes propositions (entre rappel et info):
- quitter SMF, et faire ce que l'on veut autour.
- garder SMF 2.0 le temps que la version suivante soit vraiment release. RIP http/2, PHP7 et LTS 16.04 pour un bon moment (avec le soucis de PHP 5.6 sans sécurité à partir de janvier 2019, et il y aura LTS 18.04 d'ici là).
- passer à SMF 2.1 avant la fin 2018, quitte à que ce soit encore en beta ou RC (Vivien l'a déjà fait ainsi avec la 2.0). Et faire ce que l'on veut autour à ce moment là.

Vivien espère l'option 2 avant la fin 2018 (sauf impatience), sinon ce serait l'option 3.
Ma préférée est l'option 1.

mirtouf · « **Réponse #13 le:** 11 juin 2016 à 17:50:19 »

Citation de: kgersen le 11 juin 2016 à 14:59:29

t'envisages pas un jour de laisser tomber SMF pour utiliser quelque chose de plus moderne et plus simple ? genre Discourse par exemple (a essayer ici: http://try.discourse.org/ )

associer a un "Slack like" comme http://www.mattermost.org/ par exemple.

J'approuve ce message.

vivien · « **Réponse #14 le:** 11 juin 2016 à 19:09:45 »

Pour ma part, je suis quasiment sûr qu'il vont faire les petites modif pour que SMF 2.0 soit compatible PHP 7.

Fedora 24 sort mardi prochain (14 juin 2016), Debian 9 passera en gel le 5 février 2017 pour une sortie lors de l'été 2017.
Il me semble que ces deux distributions majeures devraient avoir uniquement PHP 7. Le "rester sur l'ancienne version" ne pourra plus tenir.

Vu le gain de performance, les hébergeurs mutualisés pourraient forcer la main pour passer à PHP 7 dans un an.

Bref, je parie sur le fait que la prochaine mise à jour de sécurité de SMF 2.0 rajoutera la compatibilité PHP 7 (et la suppression de la compatibilité PHP 4)

underground78 · « **Réponse #15 le:** 12 juin 2016 à 10:18:43 »

Citation de: Huguesdelamure le 11 juin 2016 à 15:04:30

Bof, l'ergonomie de SMF est juste parfaite, Discourse me fait mal aux yeux, personnellement.

+1 (voir beaucoup plus en fait)

C'est là que je me dis que je suis déjà vieux et que je comprends plus la modernité... Ce qui me rassure c'est que Huguesdelamure est encore plus jeune que moi !

TroniQ89 · « **Réponse #16 le:** 12 juin 2016 à 12:16:49 »

Citation de: turold le 11 juin 2016 à 17:35:56

Mes propositions (entre rappel et info):
- quitter SMF, et faire ce que l'on veut autour.
- garder SMF 2.0 le temps que la version suivante soit vraiment release. RIP http/2, PHP7 et LTS 16.04 pour un bon moment (avec le soucis de PHP 5.6 sans sécurité à partir de janvier 2019, et il y aura LTS 18.04 d'ici là).
- passer à SMF 2.1 avant la fin 2018, quitte à que ce soit encore en beta ou RC (Vivien l'a déjà fait ainsi avec la 2.0). Et faire ce que l'on veut autour à ce moment là.

Vivien espère l'option 2 avant la fin 2018 (sauf impatience), sinon ce serait l'option 3.
Ma préférée est l'option 1.

Je suis de ton avis aussi

Discourse donnerait un petit coup de neuf au forum je pense. A voir après, est ce que Discourse a les balises "code" etc? Si non, y'a-t-il un plugin pour ça ?

kgersen · « **Réponse #17 le:** 12 juin 2016 à 13:03:10 »

Citation de: TroniQ89 le 12 juin 2016 à 12:16:49

Je suis de ton avis aussi
Discourse donnerait un petit coup de neuf au forum je pense. A voir après, est ce que Discourse a les balises "code" etc? Si non, y'a-t-il un plugin pour ça ?

oui Discourse a les balises 'code' etc et meme plus que ca. pour le code il sait faire de la colorisation en fonction du langage.
exemples: https://meta.discourse.org/t/syntax-highlighting-of-code-blocks/7242
(en interne Discourse utilise https://highlightjs.org/ donc fonctionne avec tout les langages supportés par highlightjs).

Discourse supporte BBCode, Markdown (utilisé par Github notamment) et HTML pour l'édition des messages.

Nh3xus · « **Réponse #18 le:** 12 juin 2016 à 13:30:31 »

Citer

HTML pour l'édition des messages.

Le truc que les sysadmins désactivent systématiquement ?

kgersen · « **Réponse #19 le:** 12 juin 2016 à 14:16:24 »

Citation de: Nh3xus le 12 juin 2016 à 13:30:31

Le truc que les sysadmins désactivent systématiquement ?

ah qui et ou ?

C'est juste du markup HTML, rien de plus et rien de dangereux. C'est un subset 'safe' d'HTML.

Apres y'a peut-etre des sysadmins ignares qui ne savent pas faire la différence entre des simples balises html et du javascript ...j'en connais

C'est le meme HTML que celui accepté par Markdown. Exemple.

turold · « **Réponse #20 le:** 12 juin 2016 à 18:06:29 »

Je fais partis des admins qui désactivent le HTML dans les messages des forums... quand j'en administre.
Je sais pourtant faire la différence entre HTML, javascript, et logiciel à part entière.

Le souci est plus du "contrôle" (ou l'impression de tout contrôler).
On sait que pour éditer un message de forum, bbcode est plus restrictif que html. Donc on cherche pas plus loin. Et ce ne sont pas les possibilités étendues en html5 qui vont inverser cette façon d'administrer un forum.

Mais de là à dire que c'est systématique: non.
Majoritaire, alors? Pas évident à dire. Il n'y a pas de statistiques dessus...

kgersen · « **Réponse #21 le:** 12 juin 2016 à 18:37:20 »

Citation de: turold le 12 juin 2016 à 18:06:29

On sait que pour éditer un message de forum, bbcode est plus restrictif que html.

'on sait' ca d'ou ? d'un passé reculé ou juste de 'l'effet mouton ou je l'ai lu sur le Net" que beaucoup d'admins pratiquent sans se donner la peine de réfléchir par eux memes ? Tres peu actualisent leur connaissances: "bah ce truc était dangereux y'a 10 ans donc c'est toujours le cas, je l'interdit". J'ai d'ailleurs participé a une époque a ce type de comportement...Les technos et produits évoluent et un bon admin est celui qui revise ses jugements et pratiques et ne reste pas coincé dans le passé.

Je ne vois pas en quoi "bbcode est plus restrictif que html" dans le cadre de Discourse par exemple, t'as un exemple ?

Apres si on parle de code de forums qui ont 10 ans ou plus ou n'ont jamais été patché/corrigé c'est sur qu'il faut interdire HTML mais pas que d'ailleurs: BBCode et les autres markups aussi. Il est vrai qu'au tout début quand on autorisait le HTML dans les posts c’était du 'HTML tel que saisie par l'utilisateur' et stocker tel que et rendu dans les pages web sans verification/traitement.

Le HTML autorisé dans les forums modernes n'a rien a voir avec ce qu'on trouvait a une époque et n'est pas plus dangereux que le BBCode et le Markdown.

Marin · « **Réponse #22 le:** 17 juin 2016 à 20:32:54 »

Citation de: turold le 11 juin 2016 à 15:08:58

Pour le tout, alors pourquoi avoir annoncé, dès le début, que t'adores SMF par rapport à la concurrence, pour raison de "sécurité", si tu sais depuis longtemps qu'à chaque version de SMF cela supporte des versions PHP plus supportées du tout depuis plus de 10 ans??

Citation de: turold le 11 juin 2016 à 15:46:29

1/ Dire qu'un composant/logiciel est sécurisé, alors qu'il se repose sur des éléments non-sécurisés, ou plus sécurisés, c'est ne prendre que la moitié de la définition de la sécurité informatique. On peut considérer que c'est mieux qu'aucune sécurité, mais bon.
Mes parents ont par exemple un antivirus à jour... mais sur Windows XP. Résultat? Aller, je vous laisse deviner...

Il y a une notion technique qui est omise ici : quand un programme instance d'un langage donné fonctionne en tant que service distant, et qu'un correctif dit de sécurité est rendu public au niveau de la bibliothèque standard de celui-ci, la non-prise en compte du patch n'est techniquement problématique que si ladite fonctionnalité est utilisée quelque part, et accepte une entrée arbitraire provenant d'un agent distant, et que l'éventuelle entrée n'est pas non plus suffisamment sanitisée à priori pour que ledit cas problématique se produise. Le champ envisageable est donc extrêmement restreint (en sachant que les composantes où ce genre de situation est la plus encline à se produire, comme une bibliothèque de manipulation d'images, sortent du cadre de la bibliothèque standard du langage) et la comparaison avec le système d'exploitation en termes d'implications globales n'est pas valable. Quand et les rares fois où on arrive à ce type de cas de figure, et pour une application de constitution open source aussi répandue que celle-ci, il paraît logique qu'un backport traitant le problème en aval sera rendu disponible rapidement.

corrector · « **Réponse #23 le:** 17 juin 2016 à 20:52:34 »

Par exemple, le parser de bash qui est fragile et sujet à débordement, on se dit que ce n'est exploitable que si on a déjà un shell bash avec une possibilité d'entrer des commandes, donc au final uniquement intéressant avec un shell restreint.

Mais une fonctionnalité non documentée de bash permettait de mettre le corps d'une fonction dans une variable d'environnement, et souvent les serveurs/clients permettent à un agent extérieur de définir le contenu de variables d'environnement dont le nom est prédéfini.

Cela montre la faible attention portée à la sécurité dans le monde GNU et chez les libristes en général, contrairement aux racontars.

Auteur Sujet: Passer le forum sous Discourse ? (Lu 17825 fois)

corrector