Configuring MODx Revolution to work with both http and https

Question

I have a website using MODx Revolution (2.2.10-pl, advanced install), let's call it www.example.com, which I want to be accessible with both http and https.

to achieve this, I tweaked the site_url context setting to be [[++url_scheme]]www.example.com/. Links created using [[~id]] seem to be alright, however, sometimes, the generated links are really weird. My interpretation is that the code to create links programmatically doesn't work with my settings, but I don't know why, or how else I would go about enabling both http and https.

Question first, examples below: How should I set the site_url or any other site/context setting so that links on my site work with both http and https? Optionally, is the behavior I see a bug, or expected behavior given Revolution's tag evaluation semantics?

---

Misbehavior examples:

When I click on "View" in the manager for a resource with the alias example, the address that is opened is

https://www.example.com/xyz/[[++url_scheme]]www.example.com/example/

where xyz is my manager URL. The expected URL is of course

https://www.example.com/example/

---

Another case where this happens is for failed logins; my login call looks like this (minus irrelevant parts):

[[!Login? &redirectToOnFailedAuth=`[[++unauthorized_page]]`]]

The unauthorized_page's expected full URL is

https://www.example.com/special/401

but the URL which is opened for a failed login as username is

https://www.example.com/[[++url_scheme]]www.example.com/[[++url_scheme]]www.example.com/special/401?u=username

The second example is the same for http, except for the scheme, of course; I haven't logged into the manager with http.

---

EDIT

.htaccess at the webroot:

RewriteEngine On
RewriteBase /

# redirect all requests to /en/favicon.ico to /favicon.ico
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(en)/favicon.ico$ favicon.ico [L,QSA]
#RewriteRule ^(en|nl|de)/favicon.ico$ favicon.ico [L,QSA]

# redirect all requests to /en/assets* /assets*
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(en)/assets(.*)$ assets$2 [L,QSA]
#RewriteRule ^(en|nl|de)/assets(.*)$ assets$2 [L,QSA]

# redirect all other requests to /en/*
# to index.php and set the cultureKey parameter
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(en)?/?(.*)$ index.php?cultureKey=$1&q=$2 [L,QSA]
#RewriteRule ^(en|nl|de)?/?(.*)$ index.php?cultureKey=$1&q=$2 [L,QSA]

.htaccess in the manager's directory:

RewriteEngine On
RewriteBase /
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/xyz/$1

Answer 1

The problem is with $modx->makeUrl(). For example, for the

[[!Login? &redirectToOnFailedAuth=`[[++unauthorized_page]]`]]

call, in core/components/login/controllers/web/Login.php:

public function checkForRedirectOnFailedAuth(modProcessorResponse $response) {
    $redirectToOnFailedAuth = $this->getProperty('redirectToOnFailedAuth',false,'isset');
    if ($redirectToOnFailedAuth && $redirectToOnFailedAuth != $this->modx->resource->get('id')) {
        $p = array(
            'u' => $this->dictionary->get('username'),
        );
        $message = $response->getMessage();
        if (!empty($message)) $params['m'] = $message;
        $url = $this->modx->makeUrl($redirectToOnFailedAuth,'',$p,'full');
        $this->modx->sendRedirect($url);
    }
}

the last two lines do a redirect to a URL generated with makeUrl, which will be something like [[++url_scheme]]www.example.com/etc (note: I'm not 100% sure here, as I can't easily look at the raw URL. The conclusions still hold, though). If the URL is simply shown on the page, this is no problem, because MODx will parse the tag before inserting it into the html output. However, as the URL is used directly for the redirect, no such replacement takes place, and the browser interprets it as a relative URL, resulting in target URLs such as https://www.example.com/[[++url_scheme]]www.example.com/etc.

So much for the problem. To avoid this, site_url must be a literal value without any tags in it. As a workaround, I now use the following snippet as the first thing in my template:

$modx->config['site_url'] = $modx->config['url_scheme'] . substr($modx->config['site_url'], strlen('[[++url_scheme]]'));
return '';

together with a [[++site_url]] of

[[++url_scheme]]www.example.com/

Note that some parts of MODx don't seem to notice this update, which is why it's important to still use [[++url_scheme]] in your site_url. As far as I can tell right now, the parts that don't see the update, stuff like [[~id]], work properly with url_scheme.

EDIT this does of course only fix the "View" buttons in the manager if you tweak the manager templates accordingly.

WARNING this is of course very hacky, and not yet tested very well. The fact that some features do not see the overwritten value means that you're introducing an inconsistency into your website, which may lead to subtle errors! If a more clean solution comes up, go for it!