#2384 (ok 3.4.0) PmaAbsoluteUri wrongly "corrected" (ssl proxy)
function checkPmaAbsoluteUri() in Config.class.php is a routine that insanely triple checks the ADMIN input made in config.inc.php. It strongly does not trust the ADMIN and overwrites the value made by the ADMIN in a way that it renders PMA useless.
This is the case if a SSL-Proxy is used. PMA thinks that the connection is HTTP and therefore changes an HTTPS starting PmaAbsoluteUri config value into the "best guessed" version by PMA.
First of all folks: Please stop ignoring the USER input (in this case user is ADMIN)! This is a dis-respect of your softwares user. This is against all usability rules.
comments like these are very disappointing:
// The URI is specified, however users do often specify this
// wrongly, so we try to fix this.
what are you doing here? are you kidding? my tip: write documentation instead of coding wired workaround that lead to malfunction. thanks.
Discussion
Logged In: YES
user_id=210714
Originator: NO
Yes, but trusting PmaAbsoluteURI means that we won't be able to see if the user has switched from http to https or the reverse.
Logged In: YES
user_id=2015842
Originator: NO
I would like to echo the comments of rbroemeling. The issue also presents itself if using a hardware load balancer that handles SSL acceleration. I'm using PMA 2.11.4.
Some form of resolution is important if PMA is to be used in this type of configuration; HTTP is not an option.
Thanks
After experimenting with a similar setup I can confirm that I have a working setup.
Both using version 2.11.9.4 and 3.1.3, without setting PmaAbsoluteUri.
I run an Apache 2.2.3 with mod_proxy accessible over https, which proxies to an plain http url.
To be able to use cookie auth apache must know that it has to rewrite set-cookie headers.
Example from the Apache 2.2 documentation:
ProxyPass /mirror/foo/ http://backend.example.com/
ProxyPassReverse /mirror/foo/ http://backend.example.com/
ProxyPassReverseCookieDomain backend.example.com public.example.com
ProxyPassReverseCookiePath / /mirror/foo/
One side-note: if the backend url looks like http://host/~user/phpmyadmin, the tilde (~) must be url encoded as %7E in the ProxyPassReverse* lines. This seems unrelated to phpmyadmin, and just the behavior of Apache.
ProxyPass /mirror/foo/ http://backend.example.com/~user/phpmyadmin
ProxyPassReverse /mirror/foo/ http://backend.example.com/%7Euser/phpmyadmin
ProxyPassReverseCookiePath /%7Euser/phpmyadmin /mirror/foo
Herman,
excuse me but you marked this as "fixed". Do you mean that the bug report was not valid?
I haven't linked it to an explicit code change in checkPmaAbsoluteUri(), but with the latest 2.x and 3.x this issue does not show for me.
An important element is however also the apache configuration telling it to reverse the cookie domain/path. Without these options the problem does occur.
The report probably was valid in that there was a combination of pma code and proxy configuration at work.
If anyone sill has a problem with this, please let me know how I could reproduce this.
Could you write a FAQ entry about this?
Marc,
FAQ 1.40 is in svn
This might also be an answer to bug #1746739: getCookiePath should use $cfg['PmaAbsoluteUri']
Hi,
i just checked the behaviour of phpmyadmin in the current version (3.1.3). It still corrects the url the wrong way, if you use a ssl proxy.
I think you missed an important point. Some ssl proxies are provided by your web hoster and you can't configure them. It is a service of your hoster, that allows you to provide ssl connections to your server without the need of getting a proper ssl certificate. Example:
https://sslproxyofhoster.tld/www.mydomain.de/
What I don't understand is:
1.
Why do you touch the PmaAbsoluteUrl Setting, if it was configured by a user? If the config value ist set, the user should know what he's doing and phpMyAdmin shouldn try to change that. The other functions like getCookiePath() and isHttps() should use this setting, too.
2.
Even if you have so many stupid users of phpMyAdmin who set this value even though they don't know what they are doing, why didn't you even consider the suggestion I made 2007-11-15? I suggested, that you could introduce a new config value, to enforce the PmaAbsolueUri setting to make absolutely sure, that even the most stupid users of PhpMyAdmin get the point. This would also make these changes totally backward compatible.
I dont't really know how you could get the config values into the static functions. I did it by including the config.inc.php directly. Maybe you know a better approach as experienced developers of phpmyadmin ;)
Would be great if this could be implemented in a future version. I hoped, that this behaviour would be corrected with the 3.x but it wasn't :(
Kind regards,
Alex.
As Alex indicates getCookiePath() would need access to the PmaAbsoluteUrl setting which has not been loaded at that point in the execution. Simply including config.inc.php directly from the static function seems like a bad idea in terms of performance and overall code style.
I suggest that we remove the check on $is_https from checkPmaAbsoluteUri() and leave that to the ForceSSL check in libraries/common.inc.php.
This leaves two minor modifications that checkPmaAbsoluteUri() can do: Adding a trailing slash, and prefixing http(s):// when missing, harmless enough not to bother the user with a warning if you ask me.
This does mean that when using a reverse proxy PmaAbsoluteUrl should always be set.
Detecting PmaAbsoluteUrl is problematic since the HTTP_VIA header contains the hostname but not the schema and path. I think we could add a warning about this on the login screen.
Remains: getCookiePath() which needs a 'hardcoded' url in scenario 3
Any suggestions?
Scenario 1: Direct connection
* cookie path OK
* absuri auto detect OK
Scenario 2: rev proxy connection same path
example: http://example.com/ --> http://internal.example.com/
* getCookiePath works OK, since it's the same path
* absuri detect fails
Scenario 3: rev proxy connection to different path
example: https://sslproxyofhoster.tld/www.mydomain.de/ --> http://www.mydomain.de internal.example.com/tools/pma/
* getCookiePath fails since internal and external paths are different
* absuri detect fails
This problem should be already fixed in Git for 3.4.0 release.
Is this really fixed? Running phpMyAdmin-4.2.2 with nginx and php-fpm, it generates a pma_absolute_uri like "http://domain.com:443/phpMyAdmin/" which of course doesn't work.