Je teste CMS Made SImple...

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

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

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

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

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

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.

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

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

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.

dans (in) fr.comp.infosystemes.www.auteurs, Mickaël Wolff
<mickael.wolff@laposte.net> ecrivait (wrote) :

Salut Mickael,

Le 23/07/2010 18:00, Eric Demeester a écrit :
> C'est vrai que c'est quand même moins merdique.

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

> 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.

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

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.

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) ?

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 :(

--
Eric

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 !