Hi Marc, Hi List,
I've updated the theme Artic Ocean for PMA 3.x https://sourceforge.net/tracker/?func=detail&aid=2964505&group_id=23...
and replaced XAMPP (Apachefriends) Theme with Smooth Yellow https://sourceforge.net/tracker/?func=detail&aid=2964529&group_id=23...
Am 05.03.2010 11:17, schrieb Michal Čihař:
On demo server, lot (maybe all) of themes throw out errors:
Call to a member function get() on a non-object in themes/aqua/css/theme_left.css.php on line 19#012 Call to a member function get() on a non-object in themes/aqua/css/theme_right.css.php on line 19#012 Call to a member function get() on a non-object in themes/aqua_brushed/css/theme_left.css.php on line 19#012 Call to a member function get() on a non-object in themes/aqua_brushed/css/theme_right.css.php on line 19#012 Call to a member function get() on a non-object in themes/arctic_ocean/css/theme_left.css.php on line 26#012 Call to a member function get() on a non-object in themes/arctic_ocean/css/theme_right.css.php on line 29#012 Call to a member function get() on a non-object in themes/clearview3/css/theme_right.css.php on line 19#012 Call to a member function get() on a non-object in themes/clearview3/css/theme_left.css.php on line 17#012
Do somebody have an idea how to fix it?
Am 06.03.2010 17:59, schrieb Marc Delisle:
There is at least one difference that I remember: the configuration was moved from session to globals.
That was the problem. Now I've fixed it with this hack:
if (isset($GLOBALS['PMA_Config']) && $GLOBALS['PMA_Config']->get('fontsize') !== null) { $pma_fsize = $GLOBALS['PMA_Config']->get('fontsize'); } else if (isset($_SESSION['PMA_Config']) && $_SESSION['PMA_Config']->get('fontsize')) { $pma_fsize = $_SESSION['PMA_Config']->get('fontsize'); } else { if (isset($_COOKIE['pma_fontsize'])) { $pma_fsize = $_COOKIE['pma_fontsize']; } } $pma_fsize = preg_replace("/[^0-9]/", "", $pma_fsize); if (!empty($pma_fsize)) { $pma_fsize = ($pma_fsize * 0.01); } else { $pma_fsize = 1; }
This can be a solution on many themes at the moment. But - why do we have so many different things to store PMA_Configs?
Regards Michael
Hi
Dne Sun, 07 Mar 2010 10:32:30 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
That was the problem. Now I've fixed it with this hack:
if (isset($GLOBALS['PMA_Config']) && $GLOBALS['PMA_Config']->get('fontsize') !== null) { $pma_fsize = $GLOBALS['PMA_Config']->get('fontsize'); } else if (isset($_SESSION['PMA_Config']) && $_SESSION['PMA_Config']->get('fontsize')) { $pma_fsize = $_SESSION['PMA_Config']->get('fontsize'); } else { if (isset($_COOKIE['pma_fontsize'])) { $pma_fsize = $_COOKIE['pma_fontsize']; } } $pma_fsize = preg_replace("/[^0-9]/", "", $pma_fsize); if (!empty($pma_fsize)) { $pma_fsize = ($pma_fsize * 0.01); } else { $pma_fsize = 1; }
This can be a solution on many themes at the moment. But - why do we have so many different things to store PMA_Configs?
It used to be in session data, but it turned out to be wrong decision - we don't want to store sensitive data in session (eg. user password would end up there). That's why it has been moved to globals (in trunk, targeted for 3.4).
Anyway I think that this code should be rather in some functions and all themes would use it.
On Mon, Mar 8, 2010 at 9:28 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Sun, 07 Mar 2010 10:32:30 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
That was the problem. Now I've fixed it with this hack:
if (isset($GLOBALS['PMA_Config']) &&
$GLOBALS['PMA_Config']->get('fontsize') !== null) {
$pma_fsize = $GLOBALS['PMA_Config']->get('fontsize');} else if (isset($_SESSION['PMA_Config']) &&
$_SESSION['PMA_Config']->get('fontsize')) {
$pma_fsize = $_SESSION['PMA_Config']->get('fontsize');} else { if (isset($_COOKIE['pma_fontsize'])) { $pma_fsize = $_COOKIE['pma_fontsize']; } } $pma_fsize = preg_replace("/[^0-9]/", "", $pma_fsize); if (!empty($pma_fsize)) { $pma_fsize = ($pma_fsize * 0.01); } else { $pma_fsize = 1; }
This can be a solution on many themes at the moment. But - why do we have so many different things to store PMA_Configs?
It used to be in session data, but it turned out to be wrong decision - we don't want to store sensitive data in session (eg. user password would end up there).
Please pardon my ignorance if this question is too trivial but what exactly is the problem in storing sensitive user information in the Session variables. I mean is it only that when running on a local machine someone might see the password in the temporary session file generated in the temp folder or something else?
That's why it has been moved to globals (in trunk, targeted for 3.4).
Anyway I think that this code should be rather in some functions and all themes would use it.
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Rohit Kalhans a écrit :
On Mon, Mar 8, 2010 at 9:28 PM, Michal Čihař <michal@cihar.com mailto:michal@cihar.com> wrote:
Hi Dne Sun, 07 Mar 2010 10:32:30 +0100 Michael Keck <sfnet@michaelkeck.de <mailto:sfnet@michaelkeck.de>> napsal(a): > That was the problem. Now I've fixed it with this hack: > > if (isset($GLOBALS['PMA_Config']) && $GLOBALS['PMA_Config']->get('fontsize') !== null) { > $pma_fsize = $GLOBALS['PMA_Config']->get('fontsize'); > } else if (isset($_SESSION['PMA_Config']) && $_SESSION['PMA_Config']->get('fontsize')) { > $pma_fsize = $_SESSION['PMA_Config']->get('fontsize'); > } else { > if (isset($_COOKIE['pma_fontsize'])) { > $pma_fsize = $_COOKIE['pma_fontsize']; > } > } > $pma_fsize = preg_replace("/[^0-9]/", "", $pma_fsize); > if (!empty($pma_fsize)) { > $pma_fsize = ($pma_fsize * 0.01); > } else { > $pma_fsize = 1; > } > > This can be a solution on many themes at the moment. > But - why do we have so many different things to store PMA_Configs? It used to be in session data, but it turned out to be wrong decision - we don't want to store sensitive data in session (eg. user password would end up there).Please pardon my ignorance if this question is too trivial but what exactly is the problem in storing sensitive user information in the Session variables. I mean is it only that when running on a local machine someone might see the password in the temporary session file generated in the temp folder or something else?
The problem is that we do not control the exact location of the session store. Some admins put it in /tmp (for example) so on a shared server, other users can peek at the files.
That's why it has been moved to globals (in trunk, targeted for 3.4). Anyway I think that this code should be rather in some functions and all themes would use it. -- Michal Čihař | http://cihar.com | http://blog.cihar.com ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net <mailto:Phpmyadmin-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel-- Rohit Kalhans
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Mon, 8 Mar 2010 21:35:08 +0530 Rohit Kalhans rohit.kalhans@gmail.com napsal(a):
Please pardon my ignorance if this question is too trivial but what exactly is the problem in storing sensitive user information in the Session variables. I mean is it only that when running on a local machine someone might see the password in the temporary session file generated in the temp folder or something else?
The problem is that on shared hosting, foreign PHP scripts can have access to the session data and steal other users credentials (unless there is something like suexec or similar solution separating users).
On Mon, Mar 8, 2010 at 9:47 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Mon, 8 Mar 2010 21:35:08 +0530 Rohit Kalhans rohit.kalhans@gmail.com napsal(a):
Please pardon my ignorance if this question is too trivial but what
exactly
is the problem in storing sensitive user information in the Session variables. I mean is it only that when running on a local machine someone might see the password in the temporary session file generated in the
temp
folder or something else?
The problem is that on shared hosting, foreign PHP scripts can have access to the session data and steal other users credentials (unless there is something like suexec or similar solution separating users).
Oh, didn't thought of that
thanx for that reply
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-
Marc Delisle -
Michael Keck -
Michal Čihař -
Rohit Kalhans