forward-port of my recent fix in branch 1.15

Also fixes edge-case situation where $_SERVER['SERVER_PORT'] is not set for an HTTPS connection, this function would return an explicit port 80 i.e. ":80" rather than an empty string.

This reverts commit 9ad60fe1.

Psalm is starting to get annoying. Both openssl_decrypt() and realpath() can return a string or false on error. Psalm seems to ignore the latter all of a sudden, so it assumes the returned variable will always be a string and then it fails when you check on errors. This fix explicitly declares the problematic variables with types string or false, so that psalm stops complaining.

This reverts commit 4f58b0ec.

Added 'no-store' to the cache-control header to prevent Google Chrome from serving the 302 redirect from disk cache

Don't bail out if the MDQ cache is broken or the query fails, because
later other metadata sources might provide the metadata for the entity.

This reverts commit 1218f38a.

When we are invoked from an outside application, SimpleSAMLphp cannot use 'baseurlpath' and in that case it tries to guess the current URL. The port was always added, even if the default port was used, leading to possible issues when comparing URLs that should actually be equivalent.

This resolves #696.

In order to fix this, we first sanitize any URL given to SimpleSAML\Utils\HTTP::checkURLAllowed() so that we make sure we have a true URL without spurious characters. Secondly, we stop using an "onload" event in the body of the redirect page to trigger the redirect automatically. Instead, we use a "meta refresh" redirection.

This double remediation is because there were two issues here: one, we were printing user input inside a chunk of javascript code. The other exploits the fact that the header() function silently breaks when a null character is part of the URL given to a "Location" header. In that case, the HTTP 302 Redirection doesn't happen, and then the browser loads the HTML and goes through it, running the injected javascript.

This fixes #699.

This method allows us to parse a URL and "rebase" it based on the $config['application']['baseURL'] configuration option. Thanks to this, applications will be able to configure a canonical base URL for the application, effectively translating any URL that might be built incorrectly (e.g. not using HTTPS because that is offloaded to a reverse proxy).

If a standard port is specified, then ignore it. Otherwise, include the port in the check so that non-standard ports must be whitelisted explicitly.

It is possible that the current script ($_SERVER['SCRIPT_FILENAME']) is inside SimpleSAMLphp's 'www' directory. However, even if that's the case, we should not enforce our base URL (as set in the 'baseurlpath' configuration option) if the request URI ($_SERVER['REQUEST_URI']) does not contain the relative path to the script. This is the case of AuthMemCookie, for example, where accessing a random URL protected by Apache, leads to the execution of a SimpleSAMLphp script, where SimpleSAML\Utils\HTTP::getSelfURL() must not try to be smart when guessing the current URL.

Recent fixes for URL guessing and building addressed bugs in the code that were preventing the 'baseurlpath' from being used properly. However, they introduced a new issue, as the code was assuming the current URL would always point to a SimpleSAMLphp script. This is not always true, of course, as any script can invoke our API and end up trying to get its own URL (for example, when calling requireAuth()).

In order to fix this, we monitor mismatches between SimpleSAMLphp's installation path and the absolute, real path to the current script. When there's a mismatch, it means we are running a third-party script outside SimpleSAMLphp, and therefore we should NOT enforce 'baseurlpath'. This introduces an additional issue, as applications behind a reverse proxy may cause trouble to guess the right URL (we will use the URL as seen by SimpleSAMLphp in the server, which is not necessarily the same as the user sees with a reverse proxy in between). For the moment, we'll leave the responsibility to sort that issue out to implementors. It might be a good idea to add a page to the wiki explaining how to do this.

This resolves #418.