Cms: The URL scheme in the baseCpUrl config value is not being respected

[sidm1983]

Description

I have a craft cms website running in headless mode and in my general.php, I have baseCpUrl set to http://localhost:8083, but when I then go to any "Pending" user in the system and click on "Copy Activation URL", the URL that gets displayed in the control panel is https://localhost:8083. The URL displayed should be using http and not https as I have used http in my baseCpUrl config value. This instance of craft is not even running in https mode, so it is strange that craft is displaying URLs with https.

Additional info

• Craft version: 3.6.4.1
• PHP version: 7.3
• Database driver & version: PGSQL 11
• Plugins & versions:

[sidm1983]

So upon further investigation, it looks like my default site's "Base URL", which was set to https://localhost:5001, was interfering with the scheme for URLs generated using the baseCpUrl value.

Changing my site's base URL to use http made the activation URL also display as http.

It looks like there is a bug where the activation URL (and possibly other CP URLs) is getting the scheme part from the site's base URL value rather than the baseCpUrl config value in general.php.

[sidm1983]

Looks like the problem is with the getSchemeForTokenizedUrl function in UrlHelper.php (line 404): https://github.com/craftcms/cms/blob/e7df93cffb09041f24af5b44f8b1215036e1cb35/src/helpers/UrlHelper.php#L404

This function doesn't check whether baseCpUrl is explicitly set and just uses the static::baseSiteUrl() function to grab the scheme from the site's base URL.

[brandonkelly]

Does the user account have permission to access the control panel? (Either set directly from their Permissions tab, or via one of their assigned user groups?)

If not, then this is working as expected, as Craft will generate an activation URL based on the front-end site’s base URL, not the control panel.

[sidm1983]

@brandonkelly, the user account in this case is an admin account, so it has full access to everything.

Also, in this case, I am running Craft CMS in headless mode, so generating an activation URL based on the front-end site doesn't make sense to me as the front-end site will almost always be a different domain name / application altogether when running in headless mode, and won't have the routing/controllers to handle requests to reset CMS passwords or activate CMS accounts.

Also, the URL is actually already being generated based on the baseCpUrl config value. The problem here is that the scheme of that final URL is based on the front-end site's base URL while the rest of the URL is based on the baseCpUrl config value.

I would expect it to use the scheme from the baseCpUrl as well if it gets the hostname from there (and vice versa). It shouldn't be mixing up the values from these two different settings in the final URL, right?

Here is a quick example to illustrate my point...

baseCpUrl config value = http://my-craft-cms-url.com (uses HTTP)
front-end site's base URL = https://my-front-end-site-url.com (uses HTTPS)

Given the above settings, when I go to the users section and copy an activation URL / password reset URL for any of the accounts, the final URL that is generated is:

https://my-craft-cms-url.com/admin/set-password?code=<random-string>&id=<some-guid>

You can see that this reset password URL is mostly correct. It has the hostname from the baseCpUrl config value, but the scheme (which should be http) is actually https which it got from the front-end site's base URL.

The function responsible for determining the scheme seems to be the getSchemeForTokenizedUrl function in UrlHelper.php (line 404) (referenced above) and this function never checks whether the baseCpUrl config value is set. There are other functions in this class that do correctly check for the baseCpUrl override, but this one doesn't and it is generating an incorrect URL as a result.

None of my reset password / account activation URLs work at the moment because of that incorrect scheme. I have to manually change it to http in order to get it working.

Please let me know your thoughts. Thank you.

[brandonkelly]

Gotcha. Was able to reproduce and just got this fixed for the next release.

To get the fix early, change your craftcms/cms requirement in composer.json to "dev-develop as 3.6.6" and run composer update.

[sidm1983]

@brandonkelly brilliant, thanks!

Will wait for it in 3.6.7. 🙌🏽👍🏽

[brandonkelly]

Craft 3.6.7 is out now with this fix. Thanks for reporting!