9 Feb
2011
9 Feb
'11
1:28 p.m.
Hi all
while looking at user preferences I've noticed that it uses
serialize/unserialize for storing the data in database. As this
functions is quite famous in terms of security, I think we
should avoid this.
Any reason for not using json encoding there instead? It encodes just
the data and would not possibly call PHP code as unserialize could do
because of objects with __wakeup() methods.
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
9 Feb
9 Feb
1:31 p.m.
Le 2011-02-09 05:28, Michal Čihař a écrit :
Hi all
while looking at user preferences I've noticed that it uses
serialize/unserialize for storing the data in database. As this
functions is quite famous in terms of security, I think we
should avoid this.
Any reason for not using json encoding there instead? It encodes just
the data and would not possibly call PHP code as unserialize could do
because of objects with __wakeup() methods.
It's also used in PHPExcel, TCPDF and tracking feature.
--
Marc Delisle
http://infomarc.info
4:54 p.m.
Hi
Dne Wed, 09 Feb 2011 05:31:19 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
Le 2011-02-09 05:28, Michal Čihař a écrit :
I don't think we use that code in PHPExcel and TCPDF, however
basically same what I wrote applies to tracking. Anyway now we have
chance to make preferences use something safer, without hurting backward
compatibility, with tracking it would be harder and some backward
compatibility probably would have to be maintained.
To exploit this, somebody would have to write custom data to pmadb...
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
Hi all
while looking at user preferences I've noticed that it uses
serialize/unserialize for storing the data in database. As this
functions is quite famous in terms of security, I think we
should avoid this.
Any reason for not using json encoding there instead? It encodes just
the data and would not possibly call PHP code as unserialize could do
because of objects with __wakeup() methods.
It's also used in PHPExcel, TCPDF and tracking feature. 
9:25 p.m.
2011/2/9 Michal Čihař <michal(a)cihar.com>om>:
Hi
Dne Wed, 09 Feb 2011 05:31:19 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
I think we can safely change user preferences to use
json_encode/decode. It's a simpler and faster solution.
--
Piotr Przybylski
Le 2011-02-09 05:28, Michal Čihař a écrit :
I don't think we use that code in PHPExcel and TCPDF, however
basically same what I wrote applies to tracking. Anyway now we have
chance to make preferences use something safer, without hurting backward
compatibility, with tracking it would be harder and some backward
compatibility probably would have to be maintained.
To exploit this, somebody would have to write custom data to pmadb...
Hi all
while looking at user preferences I've noticed that it uses
serialize/unserialize for storing the data in database. As this
functions is quite famous in terms of security, I think we
should avoid this.
Any reason for not using json encoding there instead? It encodes just
the data and would not possibly call PHP code as unserialize could do
because of objects with __wakeup() methods.
It's also used in PHPExcel, TCPDF and tracking feature.
10:18 p.m.
Hi
Dne Wed, 9 Feb 2011 19:25:47 +0100
Piotr Przybylski <piotr.prz(a)gmail.com> napsal(a):
I think we can safely change user preferences to use
json_encode/decode. It's a simpler and faster solution.
I think as well, that's why I've opened this topic.
--
Michal Čihař | http://cihar.com | http://phpmyadmin.cz
16 Feb
16 Feb
7:07 p.m.
On 09-02-11 20:18, Michal Čihař wrote:
Hi
Dne Wed, 9 Feb 2011 19:25:47 +0100
Piotr Przybylski <piotr.prz(a)gmail.com> napsal(a):
Using that should not pose a problem for user preferences.
As it's introduced in 3.4 the only problem would be preferences saved by
a 3.4 beta version.
Losing these would not be a huge issue, as long as log as pma does not
feakout over 'corrupted' preference data.
--
Met vriendelijke groet / Regards,
Herman van Rink
Initfour websolutions
I think we can safely change user preferences to
use
json_encode/decode. It's a simpler and faster solution.
I think as well,
that's why I've opened this topic.
7:25 p.m.
W dniu 16 lutego 2011 17:07 użytkownik Herman van Rink
<rink(a)initfour.nl> napisał:
On 09-02-11 20:18, Michal Čihař wrote:
When json_decode() fails it does it silently and returns a null, we
can check for it and return an empty array.
--
Piotr Przybylski
Hi
Dne Wed, 9 Feb 2011 19:25:47 +0100
Piotr Przybylski <piotr.prz(a)gmail.com> napsal(a):
Using that should not pose a problem for user preferences.
As it's introduced in 3.4 the only problem would be preferences saved by
a 3.4 beta version.
Losing these would not be a huge issue, as long as log as pma does not
feakout over 'corrupted' preference data.
I think we can safely change user preferences to
use
json_encode/decode. It's a simpler and faster solution.
I think as well,
that's why I've opened this topic.
7:31 p.m.
Hi
Dne Wed, 16 Feb 2011 17:25:26 +0100
Piotr Przybylski <piotr.prz(a)gmail.com> napsal(a):
When json_decode() fails it does it silently and
returns a null, we
can check for it and return an empty array.
Sounds good enough, can you please provide patch for the change.
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
11:57 p.m.
2011/2/16 Michal Čihař <michal(a)cihar.com>om>:
Hi
Dne Wed, 16 Feb 2011 17:25:26 +0100
Piotr Przybylski <piotr.prz(a)gmail.com> napsal(a):
Pushed to master.
--
Piotr Przybylski
When json_decode() fails it does it silently and
returns a null, we
can check for it and return an empty array.
Sounds good enough, can you please provide patch for the change.
4964
days inactive
4971
days old
8 comments
4 participants
participants (4)
-
Herman van Rink -
Marc Delisle -
Michal Čihař -
Piotr Przybylski