feat: improve multiple domain support

[kenjis]

Description
Fixes#5807
Related #6746

• add Config\App::$allowedHostnames
• update Config\App::$baseURL in IncomingRequest if HTTP_HOST is an allowed hostname

Changes:

• current_url(), base_url(), site_url() will return the URL with allowed HTTP_HOST
• previous_url() will return the site URL with allowed HTTP_HOST when cannot get it from session nor HTTP_REFERER

The following functions/methods are affected (There may be others):

• Using site_url()
  • form_open()
  • audio()
  • embed()
  • img()
  • link_tag()
  • object()
  • script_tag()
  • source()
  • video()
  • RedirectResponse::route()
  • RedirectResponse::to()
  • Toolbar::prepare()
  • Toolbar::respond()
  • anchor()
  • anchor_popup()
  • base_url()
  • previous_url()
  • url_to()
• Using base_url()
  • RedirectException in CodeIgnter.php L377
  • UserAgent::isReferral()
• Using current_url()
  • ChromeLoggerHandler::__construct()
  • CodeIgniter::storePreviousURL()
  • Pager::ensureGroup()
  • Toolbar::run()

Ref #4651

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

The clone prevents URI testing from changing the App Config globally.

[kenjis]

The reason for clone is only for testing, I would like to remove it.

--- a/system/HTTP/IncomingRequest.php+++ b/system/HTTP/IncomingRequest.php@@ -195,12 +195,7 @@ class IncomingRequest extends Request
*/
protected function detectURI(string $protocol, string $baseURL)
{
- // Passing the config is unnecessary but left for legacy purposes- // @TODO For what? Why clone?- $config = clone $this->config;- $config->baseURL = $baseURL;-- $this->setPath($this->detectPath($protocol), $config);+ $this->setPath($this->detectPath($this->config->uriProtocol), $this->config);
}
/**

[MGatner]

And deprecate the baseURL input? Is that really only for testing?

[kenjis]

Both $protocol and $baseURL of detectURI() are not needed.

__construct():

CodeIgniter4/system/HTTP/IncomingRequest.php

Line 172 in 11680d6

$this->detectURI($config->uriProtocol, $config->baseURL);

CodeIgniter4/system/HTTP/IncomingRequest.php

Lines 198 to 205 in 11680d6

	protectedfunctiondetectURI(string$protocol, string$baseURL)
	{
	// Passing the config is unnecessary but left for legacy purposes
	$config = clone$this->config;
	$config->baseURL = $baseURL;
	$this->setPath($this->detectPath($protocol), $config);
	}

[michalsn]

This may be very useful feature.

At some point we probably should consider providing some easy function (helper) to generate a URL to a different host than this defined in baseURL.

[kenjis]

Is this a breaking change?

[MGatner]

I think this is mostly okay. I want to hear more about the write-back to App Config - that seems like a pretty big possibility for issues to creep in, and ones that would be difficult to trace. As far as I can tell the logic here is all self-contained, and since current_url() uses this class we shouldn't need to touch the Config.

[MGatner]

This used to be conditional on !is_cli() - what is the justification or precedent for requiring CLI to have this set?

[MGatner]

I really don't like components updating global Config values. This seems like a bad idea. What does this fix?

[michalsn]

Without this, all helpers will return "old" URLs, not one of those defined in allowedHostnames. That's basically the whole point of all these changes.

I have an app where subdomains and custom domains are used, but I use a more dynamic approach and handle it via Registrars. I would recommend this way, but the only downside is that we can't make it work with one config variable - it's a bit more complicated.

[kenjis]

We need the current real baseURL with allowedHostnames in somewhere.
I think Config\App::$baseURL in shared Config object is best,
because the baseURL is only one in a request and never changes. I don't see any problems.

But if something wrong that I miss, we need to save the current baseURL somewhere else.
Where?

[MGatner]

I would rather see anything that needs to rely on "URL for the incoming request" to use a component that represents that (IncomingRequest, current_url(), etc). It seems very counterintuitive that our Config values are dependent on infrastructure context.

I get that this is the most straightforward approach to a fix, but I think it pokes a new hole in our architecture that is liable to leak, grow bigger, etc.

I'm not a fan of the proliferation of global URL helpers we already have but I would prefer something like current_base_url() to this.

[MGatner]

Re: Registrars... I think that is a great solution at the project level, and would encourage it for individuals who need this currently.

[kenjis]

Indeed, it may seem counter-intuitive that the value of one Config object changes dynamically.
I think it is better that the URI object in IncomingRequest has all the URL related data including the current baseURL.

[kenjis]

Go to #6785

[kenjis]

Description
Fixes#5807
Related #6746

• add Config\App::$allowedHostnames
• update Config\App::$baseURL in IncomingRequest if HTTP_HOST is an allowed hostname

Changes:

• current_url(), base_url(), site_url() will return the URL with allowed HTTP_HOST
• previous_url() will return the site URL with allowed HTTP_HOST when cannot get it from session nor HTTP_REFERER

The following functions/methods are affected (There may be others):

• Using site_url()
  • form_open()
  • audio()
  • embed()
  • img()
  • link_tag()
  • object()
  • script_tag()
  • source()
  • video()
  • RedirectResponse::route()
  • RedirectResponse::to()
  • Toolbar::prepare()
  • Toolbar::respond()
  • anchor()
  • anchor_popup()
  • base_url()
  • previous_url()
  • url_to()
• Using base_url()
  • RedirectException in CodeIgnter.php L377
  • UserAgent::isReferral()
• Using current_url()
  • ChromeLoggerHandler::__construct()
  • CodeIgniter::storePreviousURL()
  • Pager::ensureGroup()
  • Toolbar::run()

Ref #4651

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

The clone prevents URI testing from changing the App Config globally.

[kenjis]

The reason for clone is only for testing, I would like to remove it.

--- a/system/HTTP/IncomingRequest.php+++ b/system/HTTP/IncomingRequest.php@@ -195,12 +195,7 @@ class IncomingRequest extends Request
*/
protected function detectURI(string $protocol, string $baseURL)
{
- // Passing the config is unnecessary but left for legacy purposes- // @TODO For what? Why clone?- $config = clone $this->config;- $config->baseURL = $baseURL;-- $this->setPath($this->detectPath($protocol), $config);+ $this->setPath($this->detectPath($this->config->uriProtocol), $this->config);
}
/**

[MGatner]

And deprecate the baseURL input? Is that really only for testing?

[kenjis]

Both $protocol and $baseURL of detectURI() are not needed.

__construct():

CodeIgniter4/system/HTTP/IncomingRequest.php

Line 172 in 11680d6

$this->detectURI($config->uriProtocol, $config->baseURL);

CodeIgniter4/system/HTTP/IncomingRequest.php

Lines 198 to 205 in 11680d6

	protectedfunctiondetectURI(string$protocol, string$baseURL)
	{
	// Passing the config is unnecessary but left for legacy purposes
	$config = clone$this->config;
	$config->baseURL = $baseURL;
	$this->setPath($this->detectPath($protocol), $config);
	}

[michalsn]

This may be very useful feature.

At some point we probably should consider providing some easy function (helper) to generate a URL to a different host than this defined in baseURL.

[kenjis]

Is this a breaking change?

[MGatner]

I think this is mostly okay. I want to hear more about the write-back to App Config - that seems like a pretty big possibility for issues to creep in, and ones that would be difficult to trace. As far as I can tell the logic here is all self-contained, and since current_url() uses this class we shouldn't need to touch the Config.

[MGatner]

This used to be conditional on !is_cli() - what is the justification or precedent for requiring CLI to have this set?

[MGatner]

I really don't like components updating global Config values. This seems like a bad idea. What does this fix?

[michalsn]

Without this, all helpers will return "old" URLs, not one of those defined in allowedHostnames. That's basically the whole point of all these changes.

I have an app where subdomains and custom domains are used, but I use a more dynamic approach and handle it via Registrars. I would recommend this way, but the only downside is that we can't make it work with one config variable - it's a bit more complicated.

[kenjis]

We need the current real baseURL with allowedHostnames in somewhere.
I think Config\App::$baseURL in shared Config object is best,
because the baseURL is only one in a request and never changes. I don't see any problems.

But if something wrong that I miss, we need to save the current baseURL somewhere else.
Where?

[MGatner]

I would rather see anything that needs to rely on "URL for the incoming request" to use a component that represents that (IncomingRequest, current_url(), etc). It seems very counterintuitive that our Config values are dependent on infrastructure context.

I get that this is the most straightforward approach to a fix, but I think it pokes a new hole in our architecture that is liable to leak, grow bigger, etc.

I'm not a fan of the proliferation of global URL helpers we already have but I would prefer something like current_base_url() to this.

[MGatner]

Re: Registrars... I think that is a great solution at the project level, and would encourage it for individuals who need this currently.

[kenjis]

Indeed, it may seem counter-intuitive that the value of one Config object changes dynamically.
I think it is better that the URI object in IncomingRequest has all the URL related data including the current baseURL.

[kenjis]

Go to #6785

[kenjis]

Description
Fixes#5807
Related #6746

• add Config\App::$allowedHostnames
• update Config\App::$baseURL in IncomingRequest if HTTP_HOST is an allowed hostname

Changes:

• current_url(), base_url(), site_url() will return the URL with allowed HTTP_HOST
• previous_url() will return the site URL with allowed HTTP_HOST when cannot get it from session nor HTTP_REFERER

The following functions/methods are affected (There may be others):

• Using site_url()
  • form_open()
  • audio()
  • embed()
  • img()
  • link_tag()
  • object()
  • script_tag()
  • source()
  • video()
  • RedirectResponse::route()
  • RedirectResponse::to()
  • Toolbar::prepare()
  • Toolbar::respond()
  • anchor()
  • anchor_popup()
  • base_url()
  • previous_url()
  • url_to()
• Using base_url()
  • RedirectException in CodeIgnter.php L377
  • UserAgent::isReferral()
• Using current_url()
  • ChromeLoggerHandler::__construct()
  • CodeIgniter::storePreviousURL()
  • Pager::ensureGroup()
  • Toolbar::run()

Ref #4651

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

The clone prevents URI testing from changing the App Config globally.

[kenjis]

The reason for clone is only for testing, I would like to remove it.

--- a/system/HTTP/IncomingRequest.php+++ b/system/HTTP/IncomingRequest.php@@ -195,12 +195,7 @@ class IncomingRequest extends Request
*/
protected function detectURI(string $protocol, string $baseURL)
{
- // Passing the config is unnecessary but left for legacy purposes- // @TODO For what? Why clone?- $config = clone $this->config;- $config->baseURL = $baseURL;-- $this->setPath($this->detectPath($protocol), $config);+ $this->setPath($this->detectPath($this->config->uriProtocol), $this->config);
}
/**

[MGatner]

And deprecate the baseURL input? Is that really only for testing?

[kenjis]

Both $protocol and $baseURL of detectURI() are not needed.

__construct():

CodeIgniter4/system/HTTP/IncomingRequest.php

Line 172 in 11680d6

$this->detectURI($config->uriProtocol, $config->baseURL);

CodeIgniter4/system/HTTP/IncomingRequest.php

Lines 198 to 205 in 11680d6

	protectedfunctiondetectURI(string$protocol, string$baseURL)
	{
	// Passing the config is unnecessary but left for legacy purposes
	$config = clone$this->config;
	$config->baseURL = $baseURL;
	$this->setPath($this->detectPath($protocol), $config);
	}

[michalsn]

This may be very useful feature.

At some point we probably should consider providing some easy function (helper) to generate a URL to a different host than this defined in baseURL.

[kenjis]

Is this a breaking change?

[MGatner]

I think this is mostly okay. I want to hear more about the write-back to App Config - that seems like a pretty big possibility for issues to creep in, and ones that would be difficult to trace. As far as I can tell the logic here is all self-contained, and since current_url() uses this class we shouldn't need to touch the Config.

[MGatner]

This used to be conditional on !is_cli() - what is the justification or precedent for requiring CLI to have this set?

[MGatner]

I really don't like components updating global Config values. This seems like a bad idea. What does this fix?

[michalsn]

Without this, all helpers will return "old" URLs, not one of those defined in allowedHostnames. That's basically the whole point of all these changes.

I have an app where subdomains and custom domains are used, but I use a more dynamic approach and handle it via Registrars. I would recommend this way, but the only downside is that we can't make it work with one config variable - it's a bit more complicated.

[kenjis]

We need the current real baseURL with allowedHostnames in somewhere.
I think Config\App::$baseURL in shared Config object is best,
because the baseURL is only one in a request and never changes. I don't see any problems.

But if something wrong that I miss, we need to save the current baseURL somewhere else.
Where?

[MGatner]

I would rather see anything that needs to rely on "URL for the incoming request" to use a component that represents that (IncomingRequest, current_url(), etc). It seems very counterintuitive that our Config values are dependent on infrastructure context.

I get that this is the most straightforward approach to a fix, but I think it pokes a new hole in our architecture that is liable to leak, grow bigger, etc.

I'm not a fan of the proliferation of global URL helpers we already have but I would prefer something like current_base_url() to this.

[MGatner]

Re: Registrars... I think that is a great solution at the project level, and would encourage it for individuals who need this currently.

[kenjis]

Indeed, it may seem counter-intuitive that the value of one Config object changes dynamically.
I think it is better that the URI object in IncomingRequest has all the URL related data including the current baseURL.

[kenjis]

Go to #6785

[kenjis]

Description
Fixes#5807
Related #6746

• add Config\App::$allowedHostnames
• update Config\App::$baseURL in IncomingRequest if HTTP_HOST is an allowed hostname

Changes:

• current_url(), base_url(), site_url() will return the URL with allowed HTTP_HOST
• previous_url() will return the site URL with allowed HTTP_HOST when cannot get it from session nor HTTP_REFERER

The following functions/methods are affected (There may be others):

• Using site_url()
  • form_open()
  • audio()
  • embed()
  • img()
  • link_tag()
  • object()
  • script_tag()
  • source()
  • video()
  • RedirectResponse::route()
  • RedirectResponse::to()
  • Toolbar::prepare()
  • Toolbar::respond()
  • anchor()
  • anchor_popup()
  • base_url()
  • previous_url()
  • url_to()
• Using base_url()
  • RedirectException in CodeIgnter.php L377
  • UserAgent::isReferral()
• Using current_url()
  • ChromeLoggerHandler::__construct()
  • CodeIgniter::storePreviousURL()
  • Pager::ensureGroup()
  • Toolbar::run()

Ref #4651

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

The clone prevents URI testing from changing the App Config globally.

[kenjis]

The reason for clone is only for testing, I would like to remove it.

--- a/system/HTTP/IncomingRequest.php+++ b/system/HTTP/IncomingRequest.php@@ -195,12 +195,7 @@ class IncomingRequest extends Request
*/
protected function detectURI(string $protocol, string $baseURL)
{
- // Passing the config is unnecessary but left for legacy purposes- // @TODO For what? Why clone?- $config = clone $this->config;- $config->baseURL = $baseURL;-- $this->setPath($this->detectPath($protocol), $config);+ $this->setPath($this->detectPath($this->config->uriProtocol), $this->config);
}
/**

[MGatner]

And deprecate the baseURL input? Is that really only for testing?

[kenjis]

Both $protocol and $baseURL of detectURI() are not needed.

__construct():

CodeIgniter4/system/HTTP/IncomingRequest.php

Line 172 in 11680d6

$this->detectURI($config->uriProtocol, $config->baseURL);

CodeIgniter4/system/HTTP/IncomingRequest.php

Lines 198 to 205 in 11680d6

	protectedfunctiondetectURI(string$protocol, string$baseURL)
	{
	// Passing the config is unnecessary but left for legacy purposes
	$config = clone$this->config;
	$config->baseURL = $baseURL;
	$this->setPath($this->detectPath($protocol), $config);
	}

[michalsn]

This may be very useful feature.

At some point we probably should consider providing some easy function (helper) to generate a URL to a different host than this defined in baseURL.

[kenjis]

Is this a breaking change?

[MGatner]

I think this is mostly okay. I want to hear more about the write-back to App Config - that seems like a pretty big possibility for issues to creep in, and ones that would be difficult to trace. As far as I can tell the logic here is all self-contained, and since current_url() uses this class we shouldn't need to touch the Config.

[MGatner]

This used to be conditional on !is_cli() - what is the justification or precedent for requiring CLI to have this set?

[MGatner]

I really don't like components updating global Config values. This seems like a bad idea. What does this fix?

[michalsn]

Without this, all helpers will return "old" URLs, not one of those defined in allowedHostnames. That's basically the whole point of all these changes.

I have an app where subdomains and custom domains are used, but I use a more dynamic approach and handle it via Registrars. I would recommend this way, but the only downside is that we can't make it work with one config variable - it's a bit more complicated.

[kenjis]

We need the current real baseURL with allowedHostnames in somewhere.
I think Config\App::$baseURL in shared Config object is best,
because the baseURL is only one in a request and never changes. I don't see any problems.

But if something wrong that I miss, we need to save the current baseURL somewhere else.
Where?

[MGatner]

I would rather see anything that needs to rely on "URL for the incoming request" to use a component that represents that (IncomingRequest, current_url(), etc). It seems very counterintuitive that our Config values are dependent on infrastructure context.

I get that this is the most straightforward approach to a fix, but I think it pokes a new hole in our architecture that is liable to leak, grow bigger, etc.

I'm not a fan of the proliferation of global URL helpers we already have but I would prefer something like current_base_url() to this.

[MGatner]

Re: Registrars... I think that is a great solution at the project level, and would encourage it for individuals who need this currently.

[kenjis]

Indeed, it may seem counter-intuitive that the value of one Config object changes dynamically.
I think it is better that the URI object in IncomingRequest has all the URL related data including the current baseURL.

[kenjis]

Go to #6785

[kenjis]

Description
Fixes#5807
Related #6746

• add Config\App::$allowedHostnames
• update Config\App::$baseURL in IncomingRequest if HTTP_HOST is an allowed hostname

Changes:

• current_url(), base_url(), site_url() will return the URL with allowed HTTP_HOST
• previous_url() will return the site URL with allowed HTTP_HOST when cannot get it from session nor HTTP_REFERER

The following functions/methods are affected (There may be others):

• Using site_url()
  • form_open()
  • audio()
  • embed()
  • img()
  • link_tag()
  • object()
  • script_tag()
  • source()
  • video()
  • RedirectResponse::route()
  • RedirectResponse::to()
  • Toolbar::prepare()
  • Toolbar::respond()
  • anchor()
  • anchor_popup()
  • base_url()
  • previous_url()
  • url_to()
• Using base_url()
  • RedirectException in CodeIgnter.php L377
  • UserAgent::isReferral()
• Using current_url()
  • ChromeLoggerHandler::__construct()
  • CodeIgniter::storePreviousURL()
  • Pager::ensureGroup()
  • Toolbar::run()

Ref #4651

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

The clone prevents URI testing from changing the App Config globally.

[kenjis]

The reason for clone is only for testing, I would like to remove it.

--- a/system/HTTP/IncomingRequest.php+++ b/system/HTTP/IncomingRequest.php@@ -195,12 +195,7 @@ class IncomingRequest extends Request
*/
protected function detectURI(string $protocol, string $baseURL)
{
- // Passing the config is unnecessary but left for legacy purposes- // @TODO For what? Why clone?- $config = clone $this->config;- $config->baseURL = $baseURL;-- $this->setPath($this->detectPath($protocol), $config);+ $this->setPath($this->detectPath($this->config->uriProtocol), $this->config);
}
/**

[MGatner]

And deprecate the baseURL input? Is that really only for testing?

[kenjis]

Both $protocol and $baseURL of detectURI() are not needed.

__construct():

CodeIgniter4/system/HTTP/IncomingRequest.php

Line 172 in 11680d6

$this->detectURI($config->uriProtocol, $config->baseURL);

CodeIgniter4/system/HTTP/IncomingRequest.php

Lines 198 to 205 in 11680d6

	protectedfunctiondetectURI(string$protocol, string$baseURL)
	{
	// Passing the config is unnecessary but left for legacy purposes
	$config = clone$this->config;
	$config->baseURL = $baseURL;
	$this->setPath($this->detectPath($protocol), $config);
	}

[michalsn]

This may be very useful feature.

At some point we probably should consider providing some easy function (helper) to generate a URL to a different host than this defined in baseURL.

[kenjis]

Is this a breaking change?

[MGatner]

I think this is mostly okay. I want to hear more about the write-back to App Config - that seems like a pretty big possibility for issues to creep in, and ones that would be difficult to trace. As far as I can tell the logic here is all self-contained, and since current_url() uses this class we shouldn't need to touch the Config.

[MGatner]

This used to be conditional on !is_cli() - what is the justification or precedent for requiring CLI to have this set?

[MGatner]

I really don't like components updating global Config values. This seems like a bad idea. What does this fix?

[michalsn]

Without this, all helpers will return "old" URLs, not one of those defined in allowedHostnames. That's basically the whole point of all these changes.

I have an app where subdomains and custom domains are used, but I use a more dynamic approach and handle it via Registrars. I would recommend this way, but the only downside is that we can't make it work with one config variable - it's a bit more complicated.

[kenjis]

We need the current real baseURL with allowedHostnames in somewhere.
I think Config\App::$baseURL in shared Config object is best,
because the baseURL is only one in a request and never changes. I don't see any problems.

But if something wrong that I miss, we need to save the current baseURL somewhere else.
Where?

[MGatner]

I would rather see anything that needs to rely on "URL for the incoming request" to use a component that represents that (IncomingRequest, current_url(), etc). It seems very counterintuitive that our Config values are dependent on infrastructure context.

I get that this is the most straightforward approach to a fix, but I think it pokes a new hole in our architecture that is liable to leak, grow bigger, etc.

I'm not a fan of the proliferation of global URL helpers we already have but I would prefer something like current_base_url() to this.

[MGatner]

Re: Registrars... I think that is a great solution at the project level, and would encourage it for individuals who need this currently.

[kenjis]

Indeed, it may seem counter-intuitive that the value of one Config object changes dynamically.
I think it is better that the URI object in IncomingRequest has all the URL related data including the current baseURL.

[kenjis]

Go to #6785

[kenjis]

Description
Fixes#5807
Related #6746

• add Config\App::$allowedHostnames
• update Config\App::$baseURL in IncomingRequest if HTTP_HOST is an allowed hostname

Changes:

• current_url(), base_url(), site_url() will return the URL with allowed HTTP_HOST
• previous_url() will return the site URL with allowed HTTP_HOST when cannot get it from session nor HTTP_REFERER

The following functions/methods are affected (There may be others):

• Using site_url()
  • form_open()
  • audio()
  • embed()
  • img()
  • link_tag()
  • object()
  • script_tag()
  • source()
  • video()
  • RedirectResponse::route()
  • RedirectResponse::to()
  • Toolbar::prepare()
  • Toolbar::respond()
  • anchor()
  • anchor_popup()
  • base_url()
  • previous_url()
  • url_to()
• Using base_url()
  • RedirectException in CodeIgnter.php L377
  • UserAgent::isReferral()
• Using current_url()
  • ChromeLoggerHandler::__construct()
  • CodeIgniter::storePreviousURL()
  • Pager::ensureGroup()
  • Toolbar::run()

Ref #4651

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

The clone prevents URI testing from changing the App Config globally.

[kenjis]

The reason for clone is only for testing, I would like to remove it.

--- a/system/HTTP/IncomingRequest.php+++ b/system/HTTP/IncomingRequest.php@@ -195,12 +195,7 @@ class IncomingRequest extends Request
*/
protected function detectURI(string $protocol, string $baseURL)
{
- // Passing the config is unnecessary but left for legacy purposes- // @TODO For what? Why clone?- $config = clone $this->config;- $config->baseURL = $baseURL;-- $this->setPath($this->detectPath($protocol), $config);+ $this->setPath($this->detectPath($this->config->uriProtocol), $this->config);
}
/**

[MGatner]

And deprecate the baseURL input? Is that really only for testing?

[kenjis]

Both $protocol and $baseURL of detectURI() are not needed.

__construct():

CodeIgniter4/system/HTTP/IncomingRequest.php

Line 172 in 11680d6

$this->detectURI($config->uriProtocol, $config->baseURL);

CodeIgniter4/system/HTTP/IncomingRequest.php

Lines 198 to 205 in 11680d6

	protectedfunctiondetectURI(string$protocol, string$baseURL)
	{
	// Passing the config is unnecessary but left for legacy purposes
	$config = clone$this->config;
	$config->baseURL = $baseURL;
	$this->setPath($this->detectPath($protocol), $config);
	}

[michalsn]

This may be very useful feature.

At some point we probably should consider providing some easy function (helper) to generate a URL to a different host than this defined in baseURL.

[kenjis]

Is this a breaking change?

[MGatner]

I think this is mostly okay. I want to hear more about the write-back to App Config - that seems like a pretty big possibility for issues to creep in, and ones that would be difficult to trace. As far as I can tell the logic here is all self-contained, and since current_url() uses this class we shouldn't need to touch the Config.

[MGatner]

This used to be conditional on !is_cli() - what is the justification or precedent for requiring CLI to have this set?

[MGatner]

I really don't like components updating global Config values. This seems like a bad idea. What does this fix?

[michalsn]

Without this, all helpers will return "old" URLs, not one of those defined in allowedHostnames. That's basically the whole point of all these changes.

I have an app where subdomains and custom domains are used, but I use a more dynamic approach and handle it via Registrars. I would recommend this way, but the only downside is that we can't make it work with one config variable - it's a bit more complicated.

[kenjis]

We need the current real baseURL with allowedHostnames in somewhere.
I think Config\App::$baseURL in shared Config object is best,
because the baseURL is only one in a request and never changes. I don't see any problems.

But if something wrong that I miss, we need to save the current baseURL somewhere else.
Where?

[MGatner]

I would rather see anything that needs to rely on "URL for the incoming request" to use a component that represents that (IncomingRequest, current_url(), etc). It seems very counterintuitive that our Config values are dependent on infrastructure context.

I get that this is the most straightforward approach to a fix, but I think it pokes a new hole in our architecture that is liable to leak, grow bigger, etc.

I'm not a fan of the proliferation of global URL helpers we already have but I would prefer something like current_base_url() to this.

[MGatner]

Re: Registrars... I think that is a great solution at the project level, and would encourage it for individuals who need this currently.

[kenjis]

Indeed, it may seem counter-intuitive that the value of one Config object changes dynamically.
I think it is better that the URI object in IncomingRequest has all the URL related data including the current baseURL.

[kenjis]

Go to #6785

[kenjis]

Description
Fixes#5807
Related #6746

• add Config\App::$allowedHostnames
• update Config\App::$baseURL in IncomingRequest if HTTP_HOST is an allowed hostname

Changes:

• current_url(), base_url(), site_url() will return the URL with allowed HTTP_HOST
• previous_url() will return the site URL with allowed HTTP_HOST when cannot get it from session nor HTTP_REFERER

The following functions/methods are affected (There may be others):

• Using site_url()
  • form_open()
  • audio()
  • embed()
  • img()
  • link_tag()
  • object()
  • script_tag()
  • source()
  • video()
  • RedirectResponse::route()
  • RedirectResponse::to()
  • Toolbar::prepare()
  • Toolbar::respond()
  • anchor()
  • anchor_popup()
  • base_url()
  • previous_url()
  • url_to()
• Using base_url()
  • RedirectException in CodeIgnter.php L377
  • UserAgent::isReferral()
• Using current_url()
  • ChromeLoggerHandler::__construct()
  • CodeIgniter::storePreviousURL()
  • Pager::ensureGroup()
  • Toolbar::run()

Ref #4651

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

The clone prevents URI testing from changing the App Config globally.

[kenjis]

The reason for clone is only for testing, I would like to remove it.

--- a/system/HTTP/IncomingRequest.php+++ b/system/HTTP/IncomingRequest.php@@ -195,12 +195,7 @@ class IncomingRequest extends Request
*/
protected function detectURI(string $protocol, string $baseURL)
{
- // Passing the config is unnecessary but left for legacy purposes- // @TODO For what? Why clone?- $config = clone $this->config;- $config->baseURL = $baseURL;-- $this->setPath($this->detectPath($protocol), $config);+ $this->setPath($this->detectPath($this->config->uriProtocol), $this->config);
}
/**

[MGatner]

And deprecate the baseURL input? Is that really only for testing?

[kenjis]

Both $protocol and $baseURL of detectURI() are not needed.

__construct():

CodeIgniter4/system/HTTP/IncomingRequest.php

Line 172 in 11680d6

$this->detectURI($config->uriProtocol, $config->baseURL);

CodeIgniter4/system/HTTP/IncomingRequest.php

Lines 198 to 205 in 11680d6

	protectedfunctiondetectURI(string$protocol, string$baseURL)
	{
	// Passing the config is unnecessary but left for legacy purposes
	$config = clone$this->config;
	$config->baseURL = $baseURL;
	$this->setPath($this->detectPath($protocol), $config);
	}

[michalsn]

This may be very useful feature.

At some point we probably should consider providing some easy function (helper) to generate a URL to a different host than this defined in baseURL.

[kenjis]

Is this a breaking change?

[MGatner]

I think this is mostly okay. I want to hear more about the write-back to App Config - that seems like a pretty big possibility for issues to creep in, and ones that would be difficult to trace. As far as I can tell the logic here is all self-contained, and since current_url() uses this class we shouldn't need to touch the Config.

[MGatner]

This used to be conditional on !is_cli() - what is the justification or precedent for requiring CLI to have this set?

[MGatner]

I really don't like components updating global Config values. This seems like a bad idea. What does this fix?

[michalsn]

Without this, all helpers will return "old" URLs, not one of those defined in allowedHostnames. That's basically the whole point of all these changes.

I have an app where subdomains and custom domains are used, but I use a more dynamic approach and handle it via Registrars. I would recommend this way, but the only downside is that we can't make it work with one config variable - it's a bit more complicated.

[kenjis]

We need the current real baseURL with allowedHostnames in somewhere.
I think Config\App::$baseURL in shared Config object is best,
because the baseURL is only one in a request and never changes. I don't see any problems.

But if something wrong that I miss, we need to save the current baseURL somewhere else.
Where?

[MGatner]

I would rather see anything that needs to rely on "URL for the incoming request" to use a component that represents that (IncomingRequest, current_url(), etc). It seems very counterintuitive that our Config values are dependent on infrastructure context.

I get that this is the most straightforward approach to a fix, but I think it pokes a new hole in our architecture that is liable to leak, grow bigger, etc.

I'm not a fan of the proliferation of global URL helpers we already have but I would prefer something like current_base_url() to this.

[MGatner]

Re: Registrars... I think that is a great solution at the project level, and would encourage it for individuals who need this currently.

[kenjis]

Indeed, it may seem counter-intuitive that the value of one Config object changes dynamically.
I think it is better that the URI object in IncomingRequest has all the URL related data including the current baseURL.

[kenjis]

Go to #6785

[kenjis]

Description
Fixes#5807
Related #6746

• add Config\App::$allowedHostnames
• update Config\App::$baseURL in IncomingRequest if HTTP_HOST is an allowed hostname

Changes:

• current_url(), base_url(), site_url() will return the URL with allowed HTTP_HOST
• previous_url() will return the site URL with allowed HTTP_HOST when cannot get it from session nor HTTP_REFERER

The following functions/methods are affected (There may be others):

• Using site_url()
  • form_open()
  • audio()
  • embed()
  • img()
  • link_tag()
  • object()
  • script_tag()
  • source()
  • video()
  • RedirectResponse::route()
  • RedirectResponse::to()
  • Toolbar::prepare()
  • Toolbar::respond()
  • anchor()
  • anchor_popup()
  • base_url()
  • previous_url()
  • url_to()
• Using base_url()
  • RedirectException in CodeIgnter.php L377
  • UserAgent::isReferral()
• Using current_url()
  • ChromeLoggerHandler::__construct()
  • CodeIgniter::storePreviousURL()
  • Pager::ensureGroup()
  • Toolbar::run()

Ref #4651

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

The clone prevents URI testing from changing the App Config globally.

[kenjis]

The reason for clone is only for testing, I would like to remove it.

--- a/system/HTTP/IncomingRequest.php+++ b/system/HTTP/IncomingRequest.php@@ -195,12 +195,7 @@ class IncomingRequest extends Request
*/
protected function detectURI(string $protocol, string $baseURL)
{
- // Passing the config is unnecessary but left for legacy purposes- // @TODO For what? Why clone?- $config = clone $this->config;- $config->baseURL = $baseURL;-- $this->setPath($this->detectPath($protocol), $config);+ $this->setPath($this->detectPath($this->config->uriProtocol), $this->config);
}
/**

[MGatner]

And deprecate the baseURL input? Is that really only for testing?

[kenjis]

Both $protocol and $baseURL of detectURI() are not needed.

__construct():

CodeIgniter4/system/HTTP/IncomingRequest.php

Line 172 in 11680d6

$this->detectURI($config->uriProtocol, $config->baseURL);

CodeIgniter4/system/HTTP/IncomingRequest.php

Lines 198 to 205 in 11680d6

	protectedfunctiondetectURI(string$protocol, string$baseURL)
	{
	// Passing the config is unnecessary but left for legacy purposes
	$config = clone$this->config;
	$config->baseURL = $baseURL;
	$this->setPath($this->detectPath($protocol), $config);
	}

[michalsn]

This may be very useful feature.

At some point we probably should consider providing some easy function (helper) to generate a URL to a different host than this defined in baseURL.

[kenjis]

Is this a breaking change?

[MGatner]

I think this is mostly okay. I want to hear more about the write-back to App Config - that seems like a pretty big possibility for issues to creep in, and ones that would be difficult to trace. As far as I can tell the logic here is all self-contained, and since current_url() uses this class we shouldn't need to touch the Config.

[MGatner]

This used to be conditional on !is_cli() - what is the justification or precedent for requiring CLI to have this set?

[MGatner]

I really don't like components updating global Config values. This seems like a bad idea. What does this fix?

[michalsn]

Without this, all helpers will return "old" URLs, not one of those defined in allowedHostnames. That's basically the whole point of all these changes.

I have an app where subdomains and custom domains are used, but I use a more dynamic approach and handle it via Registrars. I would recommend this way, but the only downside is that we can't make it work with one config variable - it's a bit more complicated.

[kenjis]

We need the current real baseURL with allowedHostnames in somewhere.
I think Config\App::$baseURL in shared Config object is best,
because the baseURL is only one in a request and never changes. I don't see any problems.

But if something wrong that I miss, we need to save the current baseURL somewhere else.
Where?

[MGatner]

I would rather see anything that needs to rely on "URL for the incoming request" to use a component that represents that (IncomingRequest, current_url(), etc). It seems very counterintuitive that our Config values are dependent on infrastructure context.

I get that this is the most straightforward approach to a fix, but I think it pokes a new hole in our architecture that is liable to leak, grow bigger, etc.

I'm not a fan of the proliferation of global URL helpers we already have but I would prefer something like current_base_url() to this.

[MGatner]

Re: Registrars... I think that is a great solution at the project level, and would encourage it for individuals who need this currently.

[kenjis]

Indeed, it may seem counter-intuitive that the value of one Config object changes dynamically.
I think it is better that the URI object in IncomingRequest has all the URL related data including the current baseURL.

[kenjis]

Go to #6785