I received the following error while setting up a multilingual website:

Redirects to external URLs are not allowed by default, use \Drupal\Core\Routing\TrustedRedirectResponse for it.

Here is the sequence to create this error:

  • Install new 8.0.1 website using English
  • Enable Language Translation and Language Modules
  • Allow Trusted Hosts: localhost, www.localhost & es.localhost in settings.php
  • Add Spanish language
  • Set Detection & selection > Domain to www for English and es for Spanish & Save Configuration

I've done this several times in beta.

As a side note. On the "Detection & selection" screen, the user is entering "sub-domains" not "Domains" as the screen says. In this example: Example: Specifying "de.example.com" as language domain for German will result in an URL like "http://de.example.com/contact"., de is a sub-domain of example.com/. This screen should likely be changed.

Remaining tasks

  • Review #46 and determine if a different approach is needed.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Greg Sims created an issue. See original summary.

Greg Sims’s picture

I tried a fresh install this morning with the following in settings.php:

               $settings[trusted_host_patterns] = array(
                 '^localhost',
                 '^.*.localhost',
               );

The result was the same.

Greg Sims’s picture

Gábor Hojtsy’s picture

Re your side note, you personally may be entering subdomains, but it is equally possible to enter example.es, example.de, etc. or even beispiel.de and ejemplo.es, there is no requirement for them being subdomains.

Gábor Hojtsy’s picture

Priority: Normal » Major
Issue tags: +D8MI, +language-base

Saving the config does the redirect to the new domain. However in other cases, there should not be domain redirect, should there? I mean once you saved the configuration, do you have issues later on using the different domains?

Greg Sims’s picture

@Gábor Hojtsy

I tried the sequence in #1 above with 8.0.2 -- same result.

I then went to "Content" which seemed to go OK. I tried to create an Article and received: "The website encountered an unexpected error. Please try again later."

I then went back to: http://www.localhost/admin/config/regional/language and received: "The website encountered an unexpected error. Please try again later."

I conclude that the website is unusable at this point and agree with Gábor assessment of "Major" Priority. This issue would be "Critical" for anyone that needs to use domains for languages now.

swentel’s picture

So there are two problems:

- trusted url redirect (without or with trusted urls configured)
- WSOD pages for pages you don't have access to on the domain.

So at first, when configuring, you get the url trusted redirect response. Now, authenticated on my 'base' domain, I refresh the page, all links are rewritten to go to en.drupal8 which is fine, however, you get the WSOD when you then click any link or manually go to a URL for which you need a permission. (The website encountered an unexpected error. Please try again later.)

You can find 3 entries in the logs (note, the difference between 2 and 3 is very subtle: 'system/403' vs 'system/404')

1:
type: access denied
location: http://en.drupal8/admin/config/regional/language
referrer: http://drupal8/admin/config/regional/language/detection/url
message: /admin/config/regional/language

2.
type: page not found
location: http://en.drupal8/http://en.drupal8/system/403?_exception_statuscode=403...
referrer: http://drupal8/admin/config/regional/language/detection/url
message: /http://en.drupal8/system/403?destination=http%3A%2F%2Fen.drupal8%2Fadmin...

3.
type: page not found
location: http://en.drupal8/http://en.drupal8/system/403?_exception_statuscode=404...
referrer: http://drupal8/admin/config/regional/language/detection/url
message: /http://en.drupal8/system/404?_exception_statuscode=403&destination=http%...

If you are authenticated on all domains (and with the same permissions of course), all pages and submissions are fine as along as you have access.

Haven't looked deeper, but the problem seems to be a combination in building/creating the 403/404 page and redirecting of some sort.

swentel’s picture

Version: 8.0.1 » 8.0.x-dev
FileSize
926 bytes

So this fixes the redirect, but then I get into trouble with not being authenticated on that domain and not having access to the URL configure form.

Leksat’s picture

Probably this can be fixed if we extend \Drupal\Core\Routing\LocalAwareRedirectResponseTrait::isLocal() so it also checks language domains.
UPD: or maybe it should check $settings[trusted_host_patterns]?
I'm not sure what is better.

Leksat’s picture

Status: Active » Needs review
FileSize
2.09 KB

This patch fixes the issue by adding new hook_local_domains() hook.
I could not think out a better solution... I'm not even sure if \Drupal::moduleHandler() is always available in \Drupal\Core\Routing\LocalAwareRedirectResponseTrait::isLocal(). Let's see what tests will say.

Leksat’s picture

OMG, it works! :D

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Status: Needs review » Needs work

The last submitted patch, 10: 2643466-10.patch, failed testing.

brianV’s picture

Status: Needs work » Needs review

I re-tested this patch, and it's no longer failing:

https://www.drupal.org/pift-ci-job/351901

Moving back to needs review. I'd love to see it in core.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

drupalninja99’s picture

Any updates on this issue?

Fidelix’s picture

The patch in #10 solved the problem for us.

I'd like to see better documentation and coding standards on the code though.
Thanks for the excellent work!

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

pawel_r’s picture

#10 worked for me perfectly

dawehner’s picture

Issue tags: +Needs tests

We should add some test coverage if possible :)

pixelite’s picture

Issue tags: +Triaged for D8 major current state, +FLDC17

The patch in #10 applies to Drupal 8.4.x-dev, and fixes the issue documented in #6, so I'm marking as 'Triaged for D8 major current state'.

alexpott’s picture

Discussed with @catch, @cilefen, @cottser, @laurii, and @xjm. We agreed that this is a major issue - there is no workaround and you get an unexpected TrustedRedirectResponse Error whilst using the core UI.

The patch needs tests and documentation (ie hook documentation) and a change record.

One thought is that maybe we should just produce a warning a tell people to update their $settings[trusted_host_patterns] in settings.php instead of a new hook? And use it in the trait.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

hsponner’s picture

Thanks, #10 patch helped me on 8.4.0 website

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

markus_petrux’s picture

Hi all! ...patch works and fixes the issue... tested on 8.4.5.

Attached is a patch for 8.4.5, it's the same as the one in #10, but offsets fixed.

5n00py’s picture

Thanks for working patch, it fix my problem.

Not sure what is better, new hook or trusted hosts patterns.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mirsoft’s picture

Thanks, I confirm the fix #26 worked for me and fixed an annoying issue we faced a long time (and did not know the cause).

For us it appeared after adding a menu link from the language-specific subdomain (e.g. de.example.com), pointing for example to <front> and attempting to save that link. (surprisingly enough, editing that link afterwards worked without an error)

It would be great if someone who has bandwidth could implement the rest of tasks (documentation and tests) so it can proceed further.

To the question whether or not to use trusted host patterns instead - I'm not sure I'm here the right one to tell my opinion but if we treat domains like de.example.com as local domains, then I think the implementation is correct as local domains are not being added to trusted hosts.

keats76’s picture

This was still a problem for us on Drupal 8.7.6.

Our scenario:
1) We use custom sub-domains for our languages (e.g. fr.example.com, de.example.com with www.example.com as our source)
2) Add a translation for a piece of content (example: German). Save the translation.
3) Attempt to delete the translation. The deletion fails with the message: "Redirects to external URLs are not allowed by default, use \Drupal\Core\Routing\TrustedRedirectResponse for it."
4) Refresh the original page and note that the translation has now been removed.
5) It would appear that this was an annoyance, but if you try to add a new German translation for this content, the system will error because Drupal thinks that some German content remains. I think this is an artifact of our use of the Paragraphs module.

In any case, I can confirm that applying this patch against Drupal 8.7.6 core worked and we have incorporated it into our composer flow.

Considering how old this is, I would suggest adding it to core.

mbovan’s picture

I assume the target should be 8.9.x branch here. Rerolled #10 and added documentation for hook_local_domains().

BarisW’s picture

Another thing, not sure if its related.. I have a website using 2 language domains (domain.com and domain.nl).
When I go to the overview of menu links of my main menu in the English interface (/domain.com/admin/structure/menu/manage/main-navigation) I see that the Edit links (the action dropdown) next to each menu link point to /domain.nl/menu/item/123/edit (instead of .com).

Also, when I create a menu link using the .com interface, I get the "Redirects to external URLs are not allowed by default, use \Drupal\Core\Routing\TrustedRedirectResponse for it." error after submitting the form.

This only happens with domain detection, not with path prefix.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Berdir’s picture

Component: language system » routing system
Issue tags: -Needs tests
FileSize
3.76 KB

> One thought is that maybe we should just produce a warning a tell people to update their $settings[trusted_host_patterns] in settings.php instead of a new hook? And use it in the trait.

Interesting idea. Attaching a patch that does that. Seems to work well in unit tests, didn't do any real tests with it yet.

Would be nice to finally get rid of this, this is the one of the oldest patch in our project.

No interdiff as it is a completely new approach.

Berdir’s picture

Adjusting the error message a bit. How we do that seems a bit weird to me, the trigger error and the assumption that it is a "client error". Would be nice to be able to actually put the domain in the message or log it. But I hope that's out of scope ;)

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Matthijs’s picture

Updated the patch from #37, I added the missing delimiters to the preg_match in isLocal().

Status: Needs review » Needs work

The last submitted patch, 39: 2643466-39.patch, failed testing. View results

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

xjm’s picture

Issue tags: -Triaged for D8 major current state

 

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

stefank’s picture

Hi all,

Tested on 9.4.5 and patch in #31 still applies cleanly and works as expected, prevent the error message "Redirects to external URLs are not allowed by default, use \Drupal\Core\Routing\TrustedRedirectResponse for it". Also, I have tested using the new approach from #37, but still getting the same issue.

Tested on site which is multilingual, and the detection is done using url (Domain url). When adding for example a menu item and the domain url is set for example in DE and the select list field for language is set for example in FR, then Im getting the error message. The menu is added, but the screen just displays the error, which is confusing for the end user.
Trusted hosts patterns in setting.php is set as $settings['trusted_host_patterns'][] = '.*';

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Berdir’s picture

Status: Needs work » Needs review
FileSize
4.75 KB
885 bytes

Fixing the new tests.

#44: Did you use the patch from #37 or or #39? #39 should work with .* I tested that with the unit test.

That said, this shows a problem with this approach. Maybe you just did that local or for testing, but you should _not_ use that, because it completely subverts the protection that this is supposed to provided, as any URL is then trusted and will be redirected to.

I don't think this needs a change record, it's a bug and it's now fixed. Only thing would be a reminder that you should property define the trusted host patterns :)

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs change record +Needs Review Queue Initiative

Removing CR tag per #46

Verified the test fails without the fix
Data set #8 Redirects to external URLs are not allowed by default, use \Drupal\Core\Routing\TrustedRedirectResponse for it.

Verified following the steps in the IS
Patch #46 seems to solve it.

Berdir’s picture

Thanks as well.

I am a bit concerned about what I said in #46. This means that not having the trusted host patterns configured properly (which gives you a warning/error on status page but works just fine) now also completely bypasses the outgoing projection. We might need a security review here.

The implementation is based on #22, two options I can think of is explicitly check for the full/default wildcard and then disallow this, or going back to an earlier implementation with its own hook/extension point.

xjm credited catch.

xjm credited cilefen.

xjm credited lauriii.

xjm credited star-szr.

xjm’s picture

Adding credits for the triage discussion mentioned in #22 (note: Cottser has changed his username since the comment was posted.)

xjm’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs security review

#48 also sounds like this is not actually RTBC. I added #46 to the remaining tasks in the IS.

Berdir’s picture

Status: Needs review » Needs work

Yes, I'm more and more convinced that this is a bad idea. See for example the template for platform.sh projects: https://github.com/platformsh-templates/drupal10/blob/master/web/sites/d.... That will completely disable the protection for redirects to external hosts.

alexpott’s picture

Just wondering what was actually wrong with the approach in #8? Ah #32 points out the redirect can happen in other places too.

I agree with @Berdir - the security implications of falling back on the trusted hosts setting are large when you consider the default config of platform.sh. Also re-using trusted hosts here repurposes/extends its meaning which, on reflection, doesn't feel like a good idea given its role in securing your site and the role of LocalRedirectResponse.

So this brings us back to #31 as the best (or maybe least worst) solution we have.

joseph.olstad’s picture

#31 applies cleanly to D10.0.11.

johnzzon’s picture

I encountered a similar issue, but when deleting a translation of a node. I've detailed reproduction steps in another issue before I found this. Adding that issue as related.

https://www.drupal.org/project/drupal/issues/3255337

EDIT: I see now that #30 has this scenario documented already.