#2384 (ok 3.4.0) PmaAbsoluteUri wrongly "corrected" (ssl proxy)

fixed
None
1
2014-05-24
2007-03-06
hakre
No

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

1 2 > >> (Page 1 of 2)
  • hakre

    hakre - 2007-03-06

    Logged In: YES
    user_id=1213599
    Originator: YES

    or say the user that the specified value is wrong or similar.

     
  • hakre

    hakre - 2007-03-06

    Logged In: YES
    user_id=1213599
    Originator: YES

    i tried to fix this by shortcutting the whole function:

    at line #554 inserted the following code:
    $pma_absolute_uri = $this->get('PmaAbsoluteUri');
    if (strlen($pma_absolute_uri)) {
    $this->set('PmaAbsoluteUri', $pma_absolute_uri);
    return;
    }
    and deleting all cookies.

    but this did not work. major files like stylesheets aren't properly set.

     
  • hakre

    hakre - 2007-03-06

    Logged In: YES
    user_id=1213599
    Originator: YES

    latest version working for me (without the need of configuring pmaAbsoluteUri) is: phpMyAdmin - 2.8.0.3

     
  • Sebastian Mendel

    Logged In: YES
    user_id=326580
    Originator: NO

    first: "are you kidding?" no - we are not kidding.

    second: "my tip: write documentation instead of coding wired workaround that lead to malfunction. thanks." - any contribution is welcome.

    What URI do you set?
    And what URI does phpMyAdmin 'guess'?
    Which version of phpMyAdmin?
    PHP version, cgi/mod?
    Webserver?

     
  • hakre

    hakre - 2007-03-06

    Logged In: YES
    user_id=1213599
    Originator: YES

    sorry for being a little rude. i know you're not kidding.

    uri is: "https://www.example.com/www.example2.com/myadmin/"

    afterwards it is: "http://www.example2.com/myadmin/"

    this is a so called SSL-Proxy, meaning, the client can connect to the server (cluster) over ssl, there is running a proxy forwarding to www.example2.com. the connection therefore originates from 127.0.0.1 for phpmyadmin and is not SSL tunneled.

    as far as i've seen, php version information as well as sapi or cgi is not the case this time.

    p.s.:
    this dilemma can not be solved by pma and requires someone to configure pma.

    therefore i strongly argument to remove the routine as it is implemented to only gather the data from the config file first. only in case the data is not present in the configfile, a guess routine can be runned warning the user about an undone configuration of the script unless the script can successfully run without fully qualified urls (absolute uris). as the script can not run without configuration in any case (and therefore needs a fully qualified uri) just output an error message as you did before and giving a hint to the documentation which already exists. as you can see, this is already the contribution.

     
  • hakre

    hakre - 2007-03-06

    Logged In: YES
    user_id=1213599
    Originator: YES

    FYI: phpMyAdmin - 2.8.2.4 (that's the one in the 2.8 branch still downloadabel from sourceforge) is working with the configureable uri. if i remove the pmaabsoluteuri config directive it does not work. that's a workaround for me so far. I don't know which kind of changes were done since that version related to the configuration directive, i've only seen one bug related to it dated in january this year for shared hosting environments.

     
  • hakre

    hakre - 2007-03-06

    Logged In: YES
    user_id=1213599
    Originator: YES

    my fault: even version 2.8.2.4 is not properly working (CSS problem i guess). I'll try even older versions later.

     
  • Sebastian Mendel

    Logged In: YES
    user_id=326580
    Originator: NO

    i do understand

    and if you comment out the whole content of PMA_Config::checkPmaAbsoluteUri() (or just insert return; as the first line) does not help?

    (possible also delete the session cookie)

     
  • hakre

    hakre - 2007-03-07

    Logged In: YES
    user_id=1213599
    Originator: YES

    back on track: deleting session cookies as well as shortcircuiting the routine did not work out (ref: comment 2007-03-06 21:51). i don't know exactly why becaue i do know for shure that the routine messed up the config setting.

    i installed now version phpMyAdmin-2.7.0-pl2 and deleted all cookies again as well. it does work it even has not a "too large font-size" in opera as versin 2.8.0.3 had. that's a go for me but it won't solve the bug. maybe it can be used as reference version.

     
  • Jürgen Wind

    Jürgen Wind - 2007-03-07

    Logged In: YES
    user_id=1383652
    Originator: NO

    @Sebastian
    in the german forum someone with similar ssl/proxy problems described a special but interesting solution:
    http://sourceforge.net/forum/message.php?msg_id=4142414

     
  • hakre

    hakre - 2007-03-08

    Logged In: YES
    user_id=1213599
    Originator: YES

    this would be an explanation why it's not enough to only change PMA_Config::checkPmaAbsoluteUri(). i'll check if this is a fix for my scenario as well when i need to use the latest version. thanks.

     
  • Marc Delisle

    Marc Delisle - 2007-03-19
    • assigned_to: nobody --> lem9
     
  • hakre

    hakre - 2007-03-20

    Logged In: YES
    user_id=1213599
    Originator: YES

    The SSL Proxy I'm using is by my Hoster. I assume it's the mod_proxy build inside Apache:

    http://httpd.apache.org/docs/2.0/mod/mod_proxy.html

    After setting up one Apache with Proxy listening on :HTTPS you can create a simple RewriteRule to take the hostname to pass the request to out of the requesturi. That done you can create the same URL syntax as in my case since the final HTTP Host will only recieve the /myadmin request then (data taken out of your example URI).

    But I don't know any specifics of the configuration, sorry.

     
  • Marc Delisle

    Marc Delisle - 2007-03-23
    • assigned_to: lem9 --> nobody
     
  • Marc Delisle

    Marc Delisle - 2007-04-09
    • summary: PmaAbsoluteUri wrongly "corrected" --> PmaAbsoluteUri wrongly "corrected" (ssl proxy)
     
  • rbroemeling

    rbroemeling - 2007-09-19

    Logged In: YES
    user_id=1894269
    Originator: NO

    I have just encountered this issue.

    phpMyAdmin version: 2.11.0

    Setup:
    * Internal phpMyAdmin installation at b.b.b.b:80 (non-SSL).
    * SSL secured lighttpd proxy (connect to public address a.a.a.a:443), such that location https://a.a.a.a/phpmyadmin proxies to http://b.b.b.b/phpmyadmin.

    Given the above setup, phpMyAdmin rewrites the browser's URL from https://a.a.a.a/phpmyadmin to http://a.a.a.a/phpmyadmin, which doesn't work at all as a.a.a.a:80 is a closed port (443/SSL is required to connect to public address a.a.a.a).

    As has been previously presented by hakre, I would prefer it if phpMyAdmin properly respected the configuration variable PmaAbsoluteUri (which I have set to 'https://a.a.a.a/phpmyadmin/') rather than over-writing the configuration with what it thinks is best.

    I realize that this may break things for people that have their sites configured incorrectly (obviously, the over-riding of the configuration was necessary at some point), so if I might make a suggestion for a middle ground: allow a configuration flag, call it 'PmaTrustAbsoluteUri' (or similar). Have it default to FALSE (at which point, current behavior remains), but if it is set to TRUE then phpMyAdmin will never re-write PmaAbsoluteUri.

    The addition of a config flag is a bit of a hack that perhaps should not be necessary -- but the current behavior is simply incorrect. If it is not possible to correct the issue (such that phpMyAdmin always trusts PmaAbsoluteUri), then the addition of the 'PmaTrustAbsoluteUri' would at the very least allow administrators that need phpMyAdmin to do what it is told the ability to force it to.

    Thanks.

     
  • Alexander Stehlik

    Logged In: YES
    user_id=1938052
    Originator: NO

    Hi.

    I had the same problem here, and I wrote a litte workaround.

    Only problem is, that the functions isHttps() and getCookiePath() are static and have no access to the config values.

    Thats what I did:

    In config.inc.php I added a value:
    $cfg['EnforcePmaAbsoluteUri'] = true;

    In libraries/Config.class.php I added:

    - at the beginning of checkPmaAbsoluteUri()
    //Workaround for ssl Proxy
    if ($this->get('EnforcePmaAbsoluteUri')) {
    $url = parse_url ($this->get('PmaAbsoluteUri'));
    $this->set('PmaAbsoluteUri', $url);
    return;
    }
    //End of Workaround

    - at the beginning of getCookiePath()
    //Workaround for ssl Proxy
    include('./config.inc.php');
    if ($cfg['EnforcePmaAbsoluteUri']) {
    $url = parse_url ($cfg['PmaAbsoluteUri']);
    return $url['path'];
    }
    //End of Workaround

    - at the beginning of isHttps()
    //Workaround for ssl Proxy
    include('./config.inc.php');
    if ($cfg['EnforcePmaAbsoluteUri']) {
    $url = parse_url ($cfg['PmaAbsoluteUri']);
    return $url['scheme'];
    }
    //End of Workaround

    To solve the problem with the static functions I included the config.inc.php file. I didn't do any programming for phpMyAdmin before, so I'm quite sure that some experienced programmer will tell me that this is total crap, but it works for me ;)

     
  • Alexander Stehlik

    Logged In: YES
    user_id=1938052
    Originator: NO

    Oops, sorry, I had a little mistake in checkPmaAbsoluteUri()

    Actually this should be enough:

    if ($this->get('EnforcePmaAbsoluteUri')) {
    return;
    }

     
  • Obes

    Obes - 2007-11-23

    Logged In: YES
    user_id=1061529
    Originator: NO

    Can vote for this bugreport?
    I also hit this problem, that pma "corrects" my setting of PmaAbsoluteUri.
    That is a HUGE problem.

     
  • Sebastian Mendel

    Logged In: YES
    user_id=326580
    Originator: NO

    i would suggest not touching PmaAbsoluteUri if configured by the user

    marc?

     
  • Marc Delisle

    Marc Delisle - 2007-11-23

    Logged In: YES
    user_id=210714
    Originator: NO

    Sebastian, I have no problem with your suggestion.

    This code appeared in 2.5.5; I think the corresponding ChangeLog entry is
    2003-10-16 Michal Cihar <nijel@users.sourceforge.net>
    * libraries/common.lib.php3: Add some more fixes for wrongly typed
    $cfg['PmaAbsoluteUri'].

    but there is no reference to a bug report.

     
  • Sebastian Mendel

    Logged In: YES
    user_id=326580
    Originator: NO

    if we do so, is_https should check PmaAbsoluteUri first too, or?

     
  • Marc Delisle

    Marc Delisle - 2007-12-17

    Logged In: YES
    user_id=210714
    Originator: NO

    Maybe this would work:
    function checkPmaAbsoluteUri()
    {
    // Setup a default value to let the people and lazy syadmins work anyway,
    // they'll get an error if the autodetect code doesn't work
    $pma_absolute_uri = $this->get('PmaAbsoluteUri');
    // $is_https = $this->get('is_https');

    if (strlen($pma_absolute_uri) < 5
    // needed to catch http/https switch
    // || ($is_https && substr($pma_absolute_uri, 0, 6) != 'https:')
    // || (!$is_https && substr($pma_absolute_uri, 0, 5) != 'http:')

     
  • Sebastian Mendel

    Logged In: YES
    user_id=326580
    Originator: NO

    i meant static method isHttps()

     
1 2 > >> (Page 1 of 2)

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks