Problem with phpmyadmin from the user interface

[aseques]

I'm having a problem with my setup ssl + port 8443, but I think that it is also found in only ssl setups.
The problem is that when the user wants to manage a database and the server is under ssl, the function:

fsockopen(Config::get('BASE_SERVER_IP'), 80, $errno, $errstr, 5);

Should be:

fsockopen('ssl://'.Config::get('BASE_SERVER_IP'), 443, $errno, $errstr, 5);

After changing that it still don't works for me so there must be something else.
Can anyone check if it's working under ssl for them?

[aseques]

Sorry, I should have explained better.
What is not working is the direct access that the user have to manage his databse (so he doesn't need to introduce his password)
The script with problems is sql_auth.php

[nuxwin]

Hi

With your changes, the PMA authentication via redirection was worked for me.

I've follow this procedure for testing:

# cd ~
# mkdir -p certif/private
# make-ssl-cert /usr/share/ssl-cert/ssleay.cnf ./certif/private/ispcp.pem
# cd /etc/apache2/sites-available
# cp 00_master.conf 00_master_ssl.conf

In the new 00_master_ssl.conf, I've changed the port to 443, and I've added the following directives in the virtualhost:

 SSLEngine On
 SSLCertificateFile /root/certif/private/ispcp.pem

And to finish, I've enabled the module ssl and restarted Apache

# a2enmod ssl
# /etc/init.d/apache2 restart

Note: I've also added Firefox exception for my self-signed certificate.

[nuxwin]

Note: I've tested on Debian Lenny with ispCP 1.0.5.

[aseques]

Replying to nuxwin:

Note: I've tested on Debian Lenny with ispCP 1.0.5.

Did you disable the non-ssl interface? a2dissite 00_master.conf /etc/init.d/apache2 restart

Otherwise it might still work using the old connection.

[aseques]

Hi nuxwin, I just checked against trunk and I still can reproduce the same problem. When there's no control panel at 80 (I am redirecting everyone to 443) the php admin doesn't work. If I change the line to:

fsockopen('ssl://'.Config::get('BASE_SERVER_IP'), 443, $errno, $errstr, 5);

Sadly, it doesn't work yet with port 8443, there might be somethin somewhere else.

NOTE: Another interesting change would be to change in sql_auth.php from:

$out = "POST /pma/ HTTP/1.0\r\n";

To:

$out = "POST /tools/pma/ HTTP/1.0\r\n";

[nuxwin]

Hello ;

I've performed several tests and now, I can confirm the issue. First, note that I've recently rewrited the client/sql_auth.php script (moved to client/pma_auth.php) to prevent usage of regexp on larges data and some other things...

In fact, the problem described here is not due to your SSL configuration or another thing that comes from our script (older or not).

When we do the query to get the PMA headers by using an Uri such as:

https://admin.nuxwin.com:8443/client/pma_auth.php?id=16

Pma returns a 301 status code (Moved Permanently) with some headers that includes the 'Location' header.

We use the header 'Location' to redirect the user to PhpMyAdmin? after setting up all the needed cookies but the problem is that PhpMyadmin? don't includes our custom SSL port in this header. That for why the authentication fail. I've tried to set the absolute Uri in the pma config.inc.php but unfortunately, nothing's been changed. So, for now, I've used a small work around to fix the problem. I Check if we use a non standard SSL port and then, I adds the custom port manually under the header 'Location' returned by PMA before use it. That works fine so...

Note: I added the fix in my working copy. I'll commit ASAP. Also, a new parameter to be able to set a non standard SSL will come with my commit.

[nuxwin]

Oupsss, forgot my previous comment about the $cfgPmaAbsoluteUri? PMA parameter.

$cfg['PmaAbsoluteUri'] = 'https://admin.nuxwin.com:8443/pma/';

works fine.

In my previous tests, I've forgot the separator ':'

no comments...

So to resume, to fix the issue, you should just set the $cfgPmaAbsoluteUri? in your pma/config.inc.php file and force reload of it.

I will still incorporate my fix to avoid questions on the forum.

[nuxwin]

Ok, good new about this issue:

As I'm a lazy developer, I want not provide any routine to fix the parameter PmaAbsoluteUri? dynamically, so, I've searched a lot for the real reason of the bug described here.

As I've previously explained, the bug is due to the fact that the header location returned by PhpMyadmin? don't contains the custom port. To resolve this issue, we should simply perform the query by sending the correct header:

Example:

"Host: {$_SERVER['SERVER_NAME']}$port\r\n"

Where the $port variable contains our custom port like this:

:8453

God, I've searched a lot before found that, but hehe, as always the winner is nuxwin, no php.

So, no-need to set the PmaAbsoluteUri? parameter. The correct Uri is detected automatically now.

The code that doing the job:

// Prepare PhpMyadmin absolute Uri to use
if(isset($_SERVER['HTTPS']) && !empty($_SERVER['HTTPS'])) {
	$port = ($_SERVER['SERVER_PORT'] != '443')
		? ':' . $_SERVER['SERVER_PORT'] : '';

	$pmaUri = 'https://' . $_SERVER['SERVER_NAME'] . $port . '/pma/';
} else {
	$port = ($_SERVER['SERVER_PORT'] != '80')
		? ':' . $_SERVER['SERVER_PORT'] : '';
	$pmaUri = 'http://' . $_SERVER['SERVER_NAME'] . $port . '/pma/';
}

# Note: Fix for #2228 is included here (see variable $port)
stream_context_get_default(
	array(
		'http' => array(
			'method' => 'POST',
			'header' => "Host: {$_SERVER['SERVER_NAME']}$port\r\n" ..
				"Content-Type: application/x-www-form-urlencoded\r\n" .
				'Content-Length: ' . strlen($data) . "\r\n" .
				"Connection: close\r\n\r\n",
				'content' => $data,
			'user_agent' => 'Mozilla/5.0',
			'max_redirects' => 1
		)
	)
);

// Gets the headers from PhpMyAdmin
$headers = get_headers($pmaUri, true);

Note: I'll commit after having finish the ticket #2277

[nuxwin]

See r3126