Ticket #1249 (closed enhancement: wontfix)
Cachez-moi ces (un)serialize que je ne saurais voir
| Reported by: | bruno | Owned by: | team |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | module:core | Version: | 2.3 |
| Severity: | normal | Keywords: | |
| Cc: |
Description
Les fonctions *serialize sont utilisées à plein d'endroits du core.
Dans 100% des cas, le but est de stocker un tableau en base, rien de plus.
Etant donné les risques potentiels de telles méthodes (et les failles intrinsèques connues à ce jour), il faudrait les éradiquer du code.
Passer par des fonctions type json_encode/decode serait un plus, avec un fallback mode pour php < 5.2 (ou alors une implémentation de compatibilité de JSON dans clearbricks pour ces versions)
Change History
comment:2 Changed 14 years ago by bruno
- Owner changed from xave to dcteam
- Status changed from new to reviewing
=> moulinette à l'upgrade, on remplace les données sérialisées par des données jsonisées.
comment:3 Changed 14 years ago by Tomtom33
Globalement pour mais je me pose la question des grosses fermes de blog? On risque pas de créer un gros timeout en passant toutes les variables sérialisées en jsonisées? Bien sur tout dépend de leurs nombres (ce que j'ignore d'ailleurs)
comment:4 follow-up: ↓ 5 Changed 14 years ago by bruno
... d'où ma proposition à une époque d'intégrer un traitement asychrone des requêtes :)
comment:5 in reply to: ↑ 4 Changed 14 years ago by Tomtom33
Replying to bruno:
... d'où ma proposition à une époque d'intégrer un traitement asychrone des requêtes :)
Yep je sais, j'ai hésité à en parler mais je ne voulais "pourrir" le ticket avec la résolution d'un autre ;)
comment:7 Changed 14 years ago by JcDenis
Pour certains settings, j'utilisais base64_encode(serialize()) puis @unserialize(base64_decode()) ce qui est très lent et très inutiles...
...Désolé.
comment:8 Changed 14 years ago by bruno
@JcDenis?: tu n'es pas le seul, loin de là, j'use et abuse moi-même de cela. Mais c'est une mauvaise pratique, contre-balancée par le fait qu'il n'y a pas d'alternative actuellement pour des PHP < 5.2. Du coup une implémentation de JSON serait bienvenue dans clearbricks...
comment:9 Changed 14 years ago by JcDenis
Pour json, dotclear 2.4 ne requiert par php > 5.3 ;)
Je ne connais pas trop json_truc, mais si c'est mieux, il faut effectivement l'ajouter à clearbrick pour être "All php compliant"
Par contre faut pas que ça bug à l'upgrade, ça apporte des changements assez profond et le passage à la moulinette n'est pas reversible...
comment:10 Changed 14 years ago by xave
Juste une idée vague, pour la moulinette : ça pourrait être fait sans timeout de manière assez simple : en conservant le unserialize pour les settings existants mais en réencodant à json à la modif. Ou bien le test serait trop lourd ?
comment:11 Changed 14 years ago by bruno
Ce qui m'embête avec cette approche, c'est qu'à aucun moment on ne pourra être sûr qu'il ne reste plus de données sérialisées nulle part. Difficile à ce moment de virer le test dans une version ultérieure...
comment:14 Changed 12 years ago by bruno
- Milestone changed from A definir to 2.7
yeah, avec les prérequis de la 2.7, on peut remonter celui-là :P
comment:15 Changed 12 years ago by Dsls
(In [d60876d7e4e4]) Use JSON instead of serialization, see #1249
comment:22 Changed 5 years ago by franck
- Status changed from reviewing to closed
- Resolution set to wontfix
Il en reste encore ici ou là, mais dans l'ensemble on peut dire que c'est de l'histoire ancienne :-)
Ok mais quid des données sérializées dans la base ? La méthode d'encodage est identique ? Ou faut-il prévoir un je-ne-sais-quoi pour assurer la rétro-compatibilité ?