Atelier sur les syntaxes de rédaction
by tetue＠rezo.net
Coucou Dotclear !
Je vous propose de participer à un atelier de réflexion sur les syntaxes de rédaction, que j'ai déjà eu l'occasion de donner et qui a beaucoup plus :
WYSIWIG ou syntaxe ? Dotclear ou Markdown ? Après un rapide rappel des conditions de rédaction web actuelles, on étudiera comparativement les principales syntaxes dites « à balisage léger », comme Markdown, ReStructuredText, etc. Et on se donne le droit de rêver :)
Ce n'est pas un atelier technique, mais un atelier de conception partagée, ouvert à tous et toutes, développeurs comme utilisateurs (à condition toutefois d'avoir déjà rédigé sur le web).
Pour savoir où et décider quand (un soir à Paris), votez :
http://doodle.com/6f58u7kkt4mwyvyd
À bientôt !
-- Romy Têtue
http://romy.tetue.net
9 years, 10 months
De l'état des billets
by Greg
Bonjour,
Je ne sais pas si le sujet est déjà en cours de discussion.
Un simple utilisateur avec les droits "gérer ses billets" n'a pas la
liberté de modifier l'état de ses billets nouvellement créés ou déjà
présents dans la base.
Mais il peut modifier l'état par défaut de ses billets nouvellement créés
depuis ses préférences.
N'y a-t'il pas pour vous une certaine incohérence ?
Bonne journée,
--
Greg
9 years, 10 months
protection du public/ : début du recensement
by Bruno
Hello,
Je continuerai probablement sur le forum, mais il serait intéressant
d'étudier, selon l'hébergeur, les directives à mettre en place pour
empêcher d'exécuter les fichiers .php dans un répertoire donné.
Approche à mettre en place :
* dans le répertoire public de votre blog (ou de votre hébergement), créer
un répertoire testphp/
* dans ce répertoire, y placer un fichier test.php contenant <?php
phpinfo(); ?>
* essayer les différents scénarios de protection
Aller ensuite sur votreblog/public/testphp/test.php avec votre navigateur
préféré.
Le scénario est OK si la page affiche <?php phpinfo; ?>
Le scénario est KO dans les autres cas.
Les scénarios identifiés actuellement
Scénario 1 : .htaccess dans le répertoire contenant :
php_flag engine off
Scénario 2 : .htaccess dans le répertoire contenant :
SetHandler default-handler
--
Bruno
9 years, 11 months
Fwd: Dotclear <= 2.6.2 Multiple Security Vulnerabilities
by Dotclear (contact)
Bon, les gens, on a du boulot !
---------- Forwarded message ----------
From: Egidio Romano <n0b0d13s(a)gmail.com>
Date: 2014-05-14 21:20 GMT+02:00
Subject: Dotclear <= 2.6.2 Multiple Security Vulnerabilities
To: security(a)dotclear.net, contact(a)dotclear.net
Hello,
I discovered some security issues in the latest version of Dotclear, and
very likely older versions are affected as well.
1) Authentication bypass in the XML/RPC interface
This issue is due to the dcXmlRpc::setUser method
(inc/core/class.dc.xmlrpc.php) not properly verifying the provided password
before being used in a call to the dcAuth::checkUser method. This could be
exploited to bypass the authentication mechanism by calling a XML/RPC
method with a valid username and an empty password. Successful exploitation
of this issue requires the XML/RPC interface to be enabled.
2) Unrestricted file upload in the media manager
This issue is due to the filemanager::isFileExclude method
(inc/libs/clearbricks/filemanager/class.filemanager.php) not properly
verifying the extension of uploaded files. This method just checks if the
uploaded file name matches the "exclude_pattern" regular expression, which
by default is set to "/\.php$/i". This might not be enough to prevent PHP
code execution, because other extensions (like .php5, .phtml, etc...) might
be used and handled as PHP script by the web server. Furthermore, this
approach could be bypassed by uploading a file with multiple extensions
(like evil.php.foo).
3) SQL injection in admin/categories.php
Input passed via the $_POST['categories_order'] parameter to
admin/categories.php is not properly verified before being passed to
the dcBlog::updCategoryPosition method. This could be exploited to conduct
SQL injection attacks leveraging the UPDATE statement defined in
the nestedTree::updatePosition method. Successful exploitation of this
issue requires an account with the "manage categories" permission.
[-] Proof of Concept
Please fine attached two PoC scripts, which are intended to be used from
the command line (CLI):
- xmlrpc.php tries to exploit (1) and (2) together to upload a PHP file.
- sqli.php tries to exploit (3) to fetch user ID and password of a super
user.
If you have any questions or concerns about the matter above, please do not
hesitate to contact me.
Best regards,
Egidio Romano
--
Dotclear Team
9 years, 11 months
Réunion DEV IRC ce soir 21h
by Franck Paul
'Jour les gens,
Rendez-vous ce soir, 21h, pour une courte réunion IRC. On causera
essentiellement du retournement de veste à propos de la gestion des
éditeurs qui seront gérés avec Dotclear.
Sortez et affutez vos arguments ;-)
À ce soir
--
Franck
9 years, 11 months
post_editor en meta !? [was: Re: [Dotclear Tracker] [2705]: default - Addresses #1896.]
by Bruno
>
> Addresses #1896.
> Save editor in post meta
> Manage editor from preferences
> If editor saved in meta post is not the ones chosen in preferences a simple textarea is displayed.
>
>
>
Heu ... je suis le seul à trouver cet ajout de choix d'editeur en post_meta
moche et incohérent ???
J'ai du mal à voir l'intérêt de stocker au niveau du billet une préférence
utilisateur. Quel est le cas d'usage qui justifie ce choix ? D'autant que
cela va grossir la base (inutilement à mon sens), ainsi que l'empreinte
mémoire coté public de dotclear pour une information quasi-cosmétique qui
n'a de sens que coté admin...
--
Bruno
9 years, 11 months
Réunion IRC de ce soir
by Franck Paul
Dites les gens, j'ai mon fiston en vacances avec moi jusqu'à vendredi, du
coup j'aimerais repousser la réunion IRC de ce soir à lundi prochain, ça
vous irait ?
Ça n'empêche pas que je suive avec attention les discussions en cours sur
la ML (entre autre sur la gestion des caches et des requêtes SQL).
Nicolas, j'ai testé la gestion des éditeurs, ça marche au poil, au seul
bémol que je trouve un peu lourd d'être obligé de changer l'éditeur et la
syntaxe dans mes prefs avant de créer un billet qui les utilise. Faudra
qu'on réfléchisse à quelque chose la dessus, mais ça n'a rien d'urgent, on
ne change en général pas de syntaxe tous les jours (je ne parle pas du
XHTML qui reste de toute les façons possible, quelque soit la syntaxe, dès
lors qu'on utilise dcLegacyEditor ou dcCkEditor).
À vous lire…
--
Franck
9 years, 11 months
Optimisation sur getPosts
by Christopher Crouzet
¡Hola!
Je me suis recemment rendu compte que mon site a tendance a se trainer
enormement avec des temps au First Byte pouvant atteindre les 2 secondes
selon webpagetest.org.
Etant donne qu'en local les temps de chargement sont instantane, je me dis
qu'OVH pouvait ne pas etre super performant pour traiter les requetes SQL,
mais je me suis lance dans un premier profiling sommaire des requestes SQL,
histoire de.
Je suis tombe sur un truc tout bete qui pourrait etre ameliore—donner
l'option de query des posts de maniere plus rapide quand on a besoin
seulement de tres peu d'informations.
Par exemple, dans mon cas j'utilise seulement les champs `post_url` et
`post_title` quand je me sers de `<tpl:EntryNext>` et `<tpl:EntryPreview>`.
J'ai donc ecrit mes propre blocks tpl `EntryNext/Preview` et ai remplace
l'appel a la fonction `dcBlog::getNextPost` par `dcBlog::getPosts` avec le
parametre `no_content` active.
Mais ca se traine toujours un peu.
SELECT
P.post_id, P.blog_id, P.user_id, P.cat_id,
post_dt, post_tz, post_creadt, post_upddt, post_format, post_password,
post_url, post_lang, post_title, post_type, post_meta, post_status,
post_selected, post_position, post_open_comment, post_open_tb, nb_comment,
nb_trackback,
U.user_name, U.user_firstname, U.user_displayname, U.user_email,
U.user_url,
C.cat_title, C.cat_url, C.cat_desc
FROM dc_post P
INNER JOIN dc_user U ON U.user_id = P.user_id
LEFT OUTER JOIN dc_category C ON P.cat_id = C.cat_id
WHERE P.blog_id = 'default' AND
((post_status = 1 AND post_password IS NULL ) ) AND
post_type IN ('post') AND
( (post_dt = '2013-11-22 00:00:00' AND P.post_id > 1) OR post_dt >
'2013-11-22 00:00:00' )
ORDER BY post_dt ASC, P.post_id ASC
LIMIT 1
La requete ci-dessus prend entre 2.5 ms et 5 ms en local et... peut monter
jusqu'a 200-600 ms chez OVH si l'alignement des etoiles n'est pas optimal.
Maintenant, la meme requete sans les champs `post_meta` et `C.cat_desc`
prend entre 0.8 ms et 1 ms en local pour 2-5.5 ms chez OVH.
Alors effectivement il semble y avoir des problemes chez OVH, mais la
difference est d'un facteur 100 dans mon cas, ce qui n'est pas negligeable
tant de maniere relative qu'absolue.
Du coup, est-ce que ca vous semblerait etre une bonne idee de rajouter un
parametre `fast` a la methode `dcBlog::getPosts` qui n'ajouterait pas ces
champs-la ? Ou peut-etre pour plus de flexibilite (et dangerosite) ajouter
un parametre qui contiendrait les champs a exclure de la query ?
Je me suis rendu compte en faisant ca que certains champs sont obligatoires
pour que les extensions `rsExtPost` et autres fonctionnent bien, mais ca
devrait pouvoir etre contournable ?
Si l'idee vous interesse, je pourrais eventuellement me porter volontaire
pour le code si vous etes trop occupes.
Bonne journee,
Christopher.
--
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>
9 years, 11 months
