Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Je teste CMS Made SImple...

2 views
Skip to first unread message
Message has been deleted

Vincent

unread,
Jul 23, 2010, 1:38:07 PM7/23/10
to
Le 23/07/2010 19:00, Eric Demeester a écrit :
> En local c'est l'horreur, php passe son temps à me dire que timeout truc
> bidule, et je suis souvent obligé de relancer le script plusieurs fois
> C'est le premier truc qui m'est venu à l'esprit, j'ai alloué plus de
> mémoire à PHP, mais ça n'a a priori rien résolu...

J'ai trouvé ça dans les manuels de php :
if you are running a script that needs to execute for unknown time, or
forever.. you may use set_time_limit(0)

Sinon j'utilise cmsmadesimple sans problème

Mickaël Wolff

unread,
Jul 23, 2010, 3:14:55 PM7/23/10
to
Le 23/07/2010 18:38, Vincent a écrit :

> J'ai trouvé ça dans les manuels de php :
> if you are running a script that needs to execute for unknown time, or
> forever.. you may use set_time_limit(0)
>
> Sinon j'utilise cmsmadesimple sans problème

Je n'ose pas imaginé ce que tu fais lorsque le système
d'authentification de ton site ne marche plus. Tu le désactives aussi ?

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

JC_E

unread,
Jul 23, 2010, 4:14:08 PM7/23/10
to
Le 23/07/2010 19:00, Eric Demeester a écrit :

Bonjour,


>avec CMS Made Simple : http://www.cmsmadesimple.fr/
>
> J'aime bien, c'est moins bordélique que Joomla, plus moderne que SPIP,
> plus conforme à mes habitudes que WordPress et (à mon humbla avis) moins
> usine à gaz que les trois sus-cités.
> En revanche au final, si CMS Made Simple correspond plutôt bien à mes
> attentes et à ma façon de voir les choses, j'ai un gros problème : cette
> chose est lente, désespérément lente :(

Quelle version est utilisée ? syr quel PHP ?
mon conseil aller sur le forum
http://www.cmsmadesimple.fr/forum/index.php
et donner le maximum d'information pour essayer de résoudre ce souscis

A+

--
JC E.
Click here to answer / cliquez ci dessous pour me repondre
http://cerbermail.com/?ZhznliAh4V

Yop

unread,
Jul 24, 2010, 2:58:54 AM7/24/10
to
>un CMS m'évitant de tout réécrire à la main à chaque fois que je crée un
>site, après Joomla ....

Juste par curiosité et pour tirer partie de ton expérience, un exemple de
truc
que tu as du "réécrire" pour faire un site avec Joomla.
Merci
Y


Vincent

unread,
Jul 24, 2010, 8:32:09 AM7/24/10
to
Le 23/07/2010 21:14, Mickaël Wolff a écrit :
> Le 23/07/2010 18:38, Vincent a écrit :
> you may use set_time_limit(0)

> Je n'ose pas imaginé ce que tu fais lorsque le système
> d'authentification de ton site ne marche plus. Tu le désactives aussi ?

"You may" not "you have to"
En fait l'idée c'était plus de s'orienter vers un problème de time_limit
qu'un problème de mémoire

Mickaël Wolff

unread,
Jul 24, 2010, 3:58:57 PM7/24/10
to
Le 23/07/2010 18:00, Eric Demeester a écrit :

> J'aime bien, c'est moins bordélique que Joomla, plus moderne que SPIP,
> plus conforme à mes habitudes que WordPress et (à mon humbla avis) moins
> usine à gaz que les trois sus-cités.

C'est vrai que c'est quand même moins merdique.


> En revanche au final, si CMS Made Simple correspond plutôt bien à mes
> attentes et à ma façon de voir les choses, j'ai un gros problème : cette
> chose est lente, désespérément lente :(
>

> En local c'est l'horreur, php passe son temps à me dire que timeout truc
> bidule, et je suis souvent obligé de relancer le script plusieurs fois

> avant mise à jour effective de la base de données.
>
> En distant, sur mon serveur dédié, ça semble aller un peu mieux, mais ça
> reste définitivement poussif par rapport aux autres CMS testés.
>
> À votre avis, c'est une question d'espace mémoire alloué à PHP ?

C'est une grosse merde. Il ne faut pas chercher midi à quatorze
heure. Une requête HTTP doit être interprétée en consommant le moins de
mémoire et de temps CPU possible. Visiblement les gars qui ont écrit
cette horreur s'en cogne, et recommandent même d'adapter la
configuration de son serveur Web pour supporter leur bloated code. À
partir de là, on ne peut que jeter bébé avec l'eau du bain.

Et parce que troller c'est mal, voici quelques éléments pour étayer
mon propos :

Ceci est une critique gratuite (je n'enverrais pas de facture,
promis) de MadeSimpleCMS. En fait, c'est un audit (avorté) de code
couplé à un mini-test d'usabilité. Les auteurs de MadeSimpleCMS peuvent
mal le prendre, ou le considérer comme une critique qui leur permettra
d'améliorer leur logiciel (il y a toute latitude).

Tout d'abord, j'ai téléchargé
<http://jc.etiemble.free.fr/abc/uploads/File/diff_cms170-171.tar.bz2>.
Oui, j'aurais dû m'en douter que ce n'était pas la version complète.
Mais tout indiquait que c'était la version à installer : premier lien
dans la page des téléchargements, aucune mention que c'était une sorte
de patch, etc. Bref, je me suis d'abord excité sur… un tarball inutilisable.

J'ai donc réparé cette erreur en téléchargant
<http://s3.amazonaws.com/cmsms/downloads/5375/cmsmadesimple-1.7.1-full.tar.gz>
Bon, là, normalement, ça devrait le faire : c'est estampillé complet.

Commençons par détarer… argh ! Mais il m'en fout partout ! Encore un
tarball préparé par un sagouin. Sous Unix/Linux, la tradition veut qu'un
tarball soit l'archive compressée d'*UN* répertoire, et non d'une
pléthore de fichier.
Si vous voulez faire dans le microsoftisme, proposez des zip. au moins,
on s'y attendra à ce que ce soit bordélique.
Heureusement que l'expérience m'a appris à me méfier des barbares, et
d'user du flag t avant tout épanchement.

mkdir simplecms
cd simplecms
tar xjvf ../simplecms*.tar.gz

Il manque le fichier README à la racine du projet. Mais que vois-je ?
Un répertoire doc, ce n'est pas très standard, mais on va faire avec. Un
fichier doc/INSTALL.txt explique les pré-requis (qui sont d'ailleurs
dépassés, si j'en crois le site de téléchargement).
La documentation explique comment compromettre la sécurité du serveur
Web à grand coup de chmod dans sa gueule. Après tout, on est en train
d'installer un CMS écrit en PHP :D Ce qui me fascine, c'est le zèle avec
lequel le document explique comment faire sauter les verrous de
sécurité, mais élude totalement l'explication sur la manière dont on
vérifie le checksum des fichiers.
Bref, la sécurité est maltraitée, ce qui n'est pas fait pour me
rassurer. Je vous rassure, le pire est à venir.
Le point 6 est intéressant. En effet, mettre en lecture seule un
fichier à son propriétaire ne rend pas se fichier à l'abri de toute
modification. Bref, le fichier d'installation est un catalogue de
mauvaises pratiques en matière de sécurité, qui raisonnent en raison de
l'invocation de la sécurité sur une action qui n'améliore pas la sécurité.
Mais finalement, le fin du fin, c'est tout de même l'organisation des
fichiers. En effet, l'ensemble des fichiers pourront être accessibles au
public en cas d'erreur minime de configuration (genre, les fichiers PHP
sont servis sans être interprétés). C'est le genre de choses qui
arrivent, et sur lesquels les éditeurs de site web n'ont pas forcément
la main. C'est pourquoi, la bonne pratique est de ne jamais disposer des
fichiers sensibles dans un répertoire étant susceptible d'être servit
publiquement. Or, ici, aussi bien le fichier de configuration que les
fichiers de cache et les bibliothèques de fonctions sont dans un
répertoire publiquement servit. C'est une faille courante dans les CMS.

Bon, passons à l'initialisation de l'application, qu'ils appellent
installation (oui, parce que à ce niveau du mode opératoire, le logiciel
est installé).

Le premier panel propose de choisir la langue de prédilection. À ce
moment je me suis dit : « “Made Simple”, oui, le petit nom systémique de
la locale est fait simple ». Bon, passons, ce n'est pas forcément
évident de récupérer le nom du langue depuis les locales (ironie
inside), mais le pire est dans le bas de la page :

=== 8< ===
Notice: Undefined index: release_notes in
/home/builder/foreign/simplecms/tmp/templates_c/%%B6^B63^B635D704%%pagestart.tpl.php
on line 30
=== >8 ===

Pour des raisons de sécurité et de compatibilité, il est plus que
conseillé de programmer avec le maximum d'avertissement, et de gérer les
erreurs, warning et notice divers (et pas avec @).

Le second panel est une très bonne idée. J'ai été quelque peut
sarcastique sur le fichier README.txt, mais en fait, je comprends mieux
pourquoi ce n'était pas expliqué. Ceci dit, si le package transféré est
compromis, cette page peut très bien dire que tout va bien. Les plus
paranos fourniront du pain gâté à la bête pour s'assurer qu'elle ne soit
un béni oui-oui.

Au troisième panel, on s'aperçoit qu'il y a une divergence avec
l'ensemble des documentations disponibles. En effet, la présence du
fichier config.php se fait ici. Ceci dit, il n'existe pas, ce qui n'est
pas précisé dans le fichier README.txt.
Et c'est là que je vois une horreur qui confirme mes craintes. Le
système d'installation bloque parce que j'ai les flags d'erreur activés.
Mais pourquoi le logiciel ne veut pas qu'ils soient activés ? Votre code
est tellement pourri qu'il ne sait pas gérer ces propres erreurs ? De
plus, ce n'est pas la bonne manière de faire. Il ne faut pas ignorer les
erreurs. Ce qu'il faut, c'est les enregistrer (dans un fichier de log
par exemple). Le but n'est pas de les désactiver, mais de ne pas les
montrer.
Dans la même veine, la gestion des ressources est stupide. Ils
recommandent de monter les ressources atteignable en mémoire à 24M
(c'est énorme pour le traitement une requête HTTP), et de monter le
temps d'exécution maximal à 1min… de telles conditions sont idéales pour
simplifier une attaque par DDOS.
Encore des dossiers à autoriser en écriture (upload, modules), c'est la
fête du slip. Ils encouragent à interdire config.php en écriture, mais
n'hésitent pas à rendre modules inscriptible. Il va falloir m'expliquer
la logique sous-jacente.

Après avoir « corrigé » la configuration de PHP dans son traitement
des erreurs, je suis passé à la phase suivante. Bon, vérification de la
capacité à écrire du serveur Web, puis on passe à la création du compte
administrateur. Le traitement du courriel est malmené, comme d'habitude.
Mes adresses locales root, mickael ou mickael@localhost n'est pas
acceptée. Au moins il accepte mon adresse avec un +.

Panel suivant, la configuration technique. Le nom du site et la
configuration de MySQL. On ne voit pas trop la logique entre ces deux
choses. Il faut réfléchir, et imaginer que nous somme dans un panel qui
aurait pu être intitulé « Gestion du contenu ». Parce que oui, vous
n'aurez pas alors remarqué que, tout au long de la configuration de
l'application, les sections sont numérotés, mais ne sont pas nommées. Ce
pourrait être une amélioration dans l'utilisabilité de l'interface
<http://www.sensible.com/secondedition/>.
Une autre amélioration pourrait être de permettre d'utiliser un
socket fichier plutôt qu'un socket réseau, pour les gros paranoïaque de
mon acabit.

Bref, la configuration s'achève et l'ensemble semble fonctionner. Il
faudrait que je commence à utiliser le logiciel. Mais, compulsif que je
suis, j'aimerais d'abord voir à quoi ressemble le code.


Plongée !

Commençons par index.php. Après tout, c'est censé être la racine de
tout. Donc là encore, il y a l'obsession de l'usage mémoire. bon sang
les gars, si votre application dépasse un usage raisonnable de mémoire
pour manipuler du texte, c'est qu'il y a un gros problème. Pourquoi
vouloir autoriser un comportement aussi inconséquent ?
Dans les premières lignes, il y a déjà un trou de sécurité potentiel :
$_SERVER['REQUEST_URI'] = $_SERVER['PHP_SELF'] . '?' .
$_SERVER['QUERY_STRING'];
Si vous ne comprennez pas pourquoi j'ai sursauté en lisant cette
ligne, c'est que vous n'avez jamais entendu parlé de CSRF. Ce qui est
inquiétant.
die est fait pour le déboguage, et pour les exemples de code.
L'utiliser en production dans la logique de l'application n'est pas une
bonne idée car son usage mène à des comportements étranges et
incontrôlables.
Le code HTML en dur, c'est mal aussi.
Pourquoi ? Pourquoi confondre la logique d'accès à la ressource avec
sa modification ?
$params = array_merge($_GET, $_POST);

Le fichier semble consacré au bootstrap de l'application. Je dis
« semble », parce qu'aucun commentaire n'indique clairement ce que le
script est censé faire. Par exemple, on ne sait pas d'où sort $gCms. On
est obligé de deviner où ce maudit objet global est défini.

Et je vais m'arrêter là parce que j'en ai marre. Non, ce CMS est
comme les autres dans le monde PHP. Un amas de bricolages et d'idées
plus ou moins intéressantes, avec une conception incomplète et erronée
de la sécurité. C'est très crade, breaucoup de code est répété,
copié-collé, etc.

Bref, amusez-vous avec, mais à vos risques et périls.

Yop

unread,
Jul 25, 2010, 4:30:38 AM7/25/10
to
>Un amas de bricolages et d'idées plus ou moins intéressantes, avec une
>conception incomplète et erronée de la sécurité. C'est très crade, ...

Waouh ! ça décoiffe. Au moins on est fixé.
Mais au final, tu conseilles quoi ?
Merci
Y

JC_E

unread,
Jul 25, 2010, 5:20:58 AM7/25/10
to

Le 24/07/2010 21:58, Mickaël Wolff a écrit :
>>Un amas de bricolages et d'idées plus ou moins intéressantes, avec une
>>conception incomplète et erronée de la sécurité. C'est très crade, ...

Le 25/07/2010 10:30, Yop a écrit :
> Waouh ! ça décoiffe. Au moins on est fixé.
> Mais au final, tu conseilles quoi ?

Consulte le site web de Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org, Tu auras la réponse
"Adresse introuvable"

--
JC E.

Message has been deleted

Yop

unread,
Jul 25, 2010, 1:02:05 PM7/25/10
to
>qu'on m'explique que ce truc est de la daube :(

Et pourtant on lit sur le site :
"Ce logiciel de gestion de contenu web a été plusieurs fois élu meilleur cms
open source"

Je savais qu'il fallait se méfier des élections !

Mickaël Wolff

unread,
Jul 25, 2010, 1:30:35 PM7/25/10
to
Le 25/07/2010 14:58, Eric Demeester a écrit :

> Un bon point, donc, mais à lire la suite, c'est à peu près le seul :(

:D Il y en a un ! Au vu de mes exigences, c'est déjà énorme.


> [snip ton analyse, merci d'avoir du temps pour la faire...]

C'est un exercice que j'aime beaucoup faire, car il m'apporte
beaucoup. Parfois en râlant, je me rends compte que, finalement, ce
n'est pas si bête que ça. D'autres fois, j'apprends ce qu'il ne faut
surtout pas faire.


> J'avoue que ton opinion (que j'estime et respecte) me met un grand coup
> au moral, parce que je pensais avoir trouvé « le CMS » correspondant à
> mes souhaits, mais que là, compte tenu de ton analyse...
>
> Finalement, j'en reviens à ma question initiale (peut-être pas formulée
> comme ça dans ce fil) consistant à me demander quelle solution
> adopter... Faut-il utiliser un CMS préfabriqué ou tout écrire à la main
> (j'ai les connaissances, je sais faire, mais s'il existe du préfabriqué
> utilisable, ce serait idiot de s'en passer) ?

Mon opinion est peut-être trop tranchante. Ceci dit, tout dépend de
tes critères. C'est toujours le même soucis. Il faut malheureusement
faire des concessions quand on choisit un outil préfabriqué.


> Là, après avoir lu les réponses à mon message, je suis plutôt désabusé,
> parce que j'ai consacré plusieurs semaines à dompter CMS Made Simple, à
> entrer des informations dans sa base de données, et voila qu'on


> m'explique que ce truc est de la daube :(

La plupart des applications écrites en PHP sont du même tonneau. Si
ce CMS répond à ton besoin immédiat, et que tu suis la vie du logiciel
(mise à jour de sécurité, etc), peut-être que ce logiciel te correspond.
Et puis, les problèmes de performance devraient devenir suffisamment
importants pour que les développeurs de CMSMadeSimple commencent à s'en
inquiéter. Ou pas.

Mickaël Wolff

unread,
Jul 25, 2010, 1:35:38 PM7/25/10
to

De choisir en connaissance de cause. Ce n'est pas parce qu'il est
dangereux de vivre que les gens restent prostrés chez eux ;)
En ce qui concerne le choix à proprement parlé, en tant que
développeur il est assez vite fait. Pour moi un CMS est un non-sens. Vim
et git remplissent ces fonctions (écriture et versionning). Mais j'ai
bien conscience qu'on ne peut pas exiger de tout le monde d'écrire du
HTML brut de décoffrage. Mais c'est tellement plus simple que de s'en
merder avec une interface Web :-/

Sergio

unread,
Jul 25, 2010, 2:48:24 PM7/25/10
to
Le 25/07/2010 19:35, Mickaël Wolff a écrit :

> De choisir en connaissance de cause. Ce n'est pas parce qu'il est dangereux de vivre que les gens restent prostrés chez eux ;)
> En ce qui concerne le choix à proprement parlé, en tant que développeur il est assez vite fait. Pour moi un CMS est un non-sens. Vim
> et git remplissent ces fonctions (écriture et versionning). Mais j'ai bien conscience qu'on ne peut pas exiger de tout le monde
> d'écrire du HTML brut de décoffrage. Mais c'est tellement plus simple que de s'en merder avec une interface Web :-/


Real programmer uses cat>index.html

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org

Pierre Goiffon

unread,
Jul 26, 2010, 9:58:14 AM7/26/10
to
Bonjour,

Merci à Eric et Michaël pour leurs retours, j'avais vu ce CMS utilisé et
j'ai depuis comme idée de l'utiliser pour un site !

Michaël, en tant que développeur d'application web je trouve votre avis
particulièrement rigoriste : tout traitement que l'on fait exécuter par
le serveur pourra être objet de problèmes de sécurité (ouvrir un
répertoire en écriture ? Ca parait difficile de proposer l'upload de
fichiers sans...), et de manière plus générale tout produit open Source
et développé par une communauté est sujet à ce genre de problématiques
(disparités dans l'équipe de développement).

Vos jugements seraient à mettre en rapport avec une étude d'un autre
produit équivalent...
Pour avoir une idée plus précise, il faudrait aller voir la forge ou au
moins le bug tracker du produit pour se faire une idée de la manière de
fonctionner de l'équipe, et vérifier les temps de correction. Mais
apparemment la forge n'est accessible qu'avec login ?
(http://dev.cmsmadesimple.org/)

JC_E

unread,
Jul 26, 2010, 12:06:42 PM7/26/10
to
Le 26/07/2010 15:58, Pierre Goiffon a écrit :
Bonjour,

> Pour avoir une idée plus précise, il faudrait aller voir la forge ou au
> moins le bug tracker du produit pour se faire une idée de la manière de
> fonctionner de l'équipe, et vérifier les temps de correction. Mais
> apparemment la forge n'est accessible qu'avec login ?
> (http://dev.cmsmadesimple.org/)

Non non, le login permet des actions supplémentaires (ex soumette un Bug
) mais vous pouvez consulter chaque projet
par exemple le (core)cms
http://dev.cmsmadesimple.org/projects/cmsmadesimple
vous avez accès aux onglets en particulier Bug Tracker
A ce jour la dernière version étant la 1.8.1 il n'y a pas de problème de
sécurité ou de faille non détectées.

Pour info http://geekmoot.com/2010/

Message has been deleted
Message has been deleted
0 new messages