phpmyadmin authentication issue.

5 posts / 0 new
Last post
#1 Wed, 01/06/2010 - 06:20
expro

phpmyadmin authentication issue.

Hi guys!

I have virtual-servers running php via cgi and suexec and recently I've installed phpmyadmin on a test account and i'm unable to login... After some time of research i discovered, that "cookie" and "http" authentication methods doesn't work because phpmyadmin writes cookies with "path=/cgi-bin/", which is obviously wrong. Any ideas how to force phpmyadmin or change virtual-server configuration that cookies were written with "path=/"?

Greets.

Wed, 01/06/2010 - 07:04
expro

In phpmyadmin version 3.2.3 cookies paths are created in the "libraries/Config.class.php" script by the function "getCookiePath()". From what I see PMA takes the "SCRIPT_NAME" env variable using "PMA_getenv('SCRIPT_NAME')" function and it parses it with:

$cookie_path   = substr($parsed_url['path'], 0, strrpos($parsed_url['path'], '/'))  . '/';

Because "_SERVER["SCRIPT_NAME"]" lookes like "/cgi-bin/php5.cgi" when php is running via suexec as CGI the cookie path results in:

Set-Cookie: pma_fontsize=82%25; expires=Fri, 05-Feb-2010 12:48:14 GMT; path=/cgi-bin/; httponly

Set-Cookie: pma_fontsize=82%25; expires=Fri, 05-Feb-2010 12:48:14 GMT; path=/cgi-bin/; httponly

Set-Cookie: pma_theme=deleted; expires=Tue, 06-Jan-2009 12:48:13 GMT; path=/cgi-bin/
Set-Cookie: pmaPass-1=wdd121; expires=Fri, 05-Feb-2010 12:48:14 GMT; path=/cgi-bin/; httponly

The following patch proves that I'm right but it's not a solution in any means. Any ideas how to solve this problem?

--- libraries/Config.class.php  2009-12-28 16:11:01.000000000 +0100
+++ libraries/Config.class.php.new  2010-01-06 13:49:26.000000000 +0100
@@ -864,7 +864,8 @@ class PMA_Config
     static public function getCookiePath()
     {
         static $cookie_path = null;
-
+       $cookie_path = '/';
+       return $cookie_path;
         if (null !== $cookie_path) {
             return $cookie_path;
         }
Wed, 01/06/2010 - 10:07
andreychek

Hrm, I don't seem to be running into the same trouble that you are, and I'm using phpMyAdmin 3.2.3 with the "cookie" auth type, using FCGID/suexec.

Looking in the getCookiePath function you're patching above, there's code like this:

        if (PMA_getenv('REQUEST_URI')) {
            $url = PMA_getenv('REQUEST_URI');
        }

The SCRIPT_NAME variable only appears to be read if you're running on a Windows system.... and then, only if $url isn't set.

One possibility is that if Apache or PHP, for one reason or another, isn't setting the REQUEST_URI environment variable, that would certainly cause some trouble.

The is, looking at the following code:

        if (empty($url)) {
            if ($GLOBALS['PMA_PHP_SELF']) {
                // PHP_SELF in CGI often points to cgi executable, so use it
                // as last choice
                $url = $GLOBALS['PMA_PHP_SELF'];

The best I can come up with is that $url is blank at the time it hits the above, and then uses PMA_PHP_SELF to fill the cookie path.

Is there something unusual about your setup that might cause REQUEST_URI to not be set?

If, on that same Virtual Server, you setup a script that executes php_info() -- do you see any output for REQUEST_URI listed in it?

-Eric

Wed, 02/03/2010 - 10:08
andreychek

You may have found a way to resolve this by now, but I ended up having a similar problem to this after upgrading to PHP 5.2.12 on a particular server, which sets SCRIPT_NAME differently.

After quite a bit of tinkering, I ended up using this hack to get around the problem --

  • Edit the Virtual Server's php.ini file, and set "auto_prepend_file = /path/to/change_phps_vars.php"

  • Then create the above script, /path/to/fix_phps_vars.php, with something like the following:

<?php
        $_SERVER['SCRIPT_NAME'] = $_SERVER["SCRIPT_URL"];
?>

Now, each time a PHP app runs, this code will be executed -- changing the SCRIPT_NAME to what the app is expecting.

I'm not sure what all the above might break, and I only did this on a Virtual Server dedicated to phpMyAdmin, but it does seem to do the trick for that :-)

-Eric

Thu, 02/11/2010 - 10:02 (Reply to #4)
expro

Hi andreychek,

I was struggeling with this issue for some time. Problem with phpMyAdmin I solved by patching it but it was an ugly bypass of the problem rather than solution. I've found out that the problem relates also to other software like joomla, cake etc. All links were created with "/cgi-bin/" taken from "$_SERVER['SCRIPT_NAME']". It was solved by specifying in the configuration files things like "absolute_uri", "baseUrl", "live_site" etc. But it also was also a dirty solution. It should work out of the box!;-)

So the problem was finally solved... You were close;-) In the "php.ini" there should be uncommented directive "cgi.fix_pathinfo" and changed from default "1" to "0". It solves the problem;-) Put it in your "php.ini" template and change it in all already created virtual-servers.

In case someone would need it (run in your AP_DOC_ROOT (check it by running suexec -V)):

find . -name php.ini | xargs perl -pi -e 's/\; cgi.fix_pathinfo=1/cgi.fix_pathinfo=0/g'

P.S

The above solution solves the problem with links creation in joomla etc. but for phpMyAdmin the problem still persists. So it seems I will stick with my patch and post action script;-)

Regards, Filip

Topic locked