New ApplicationUrl detected frequently with Umbraco 7.8.1 Multiple Domains
We've got a single Umbraco instance running 7 Umbraco websites right now. I've recently upgraded to Umbraco 7.8.1 and in UmbracoTraceLog, I'm getting these log entries every time a URL is requested across all of our different websites.
2018-02-19 12:08:26,168 [P10500/D13/T45] INFO Umbraco.Core.Sync.ApplicationUrlHelper - New ApplicationUrl detected: https://www.rocketfailover.com:443/umbraco
2018-02-19 12:08:26,173 [P10500/D13/T45] INFO Umbraco.Core.Sync.ApplicationUrlHelper - ApplicationUrl: https://www.thinix.com/umbraco (using web.routing/@umbracoApplicationUrl)
2018-02-19 12:08:29,268 [P10500/D13/T16] INFO Umbraco.Core.Sync.ApplicationUrlHelper - New ApplicationUrl detected: https://www.rdiworks.com:443/umbraco
2018-02-19 12:08:29,268 [P10500/D13/T16] INFO Umbraco.Core.Sync.ApplicationUrlHelper - ApplicationUrl: https://www.thinix.com/umbraco (using web.routing/@umbracoApplicationUrl)
2018-02-19 12:08:58,069 [P10500/D13/T58] INFO umbraco.BusinessLogic.Log - Log scrubbed. Removed all items older than 2018-02-18 12:08:58
2018-02-19 12:09:01,624 [P10500/D13/T59] INFO Umbraco.Core.Sync.ApplicationUrlHelper - New ApplicationUrl detected: https://www.audioengineering.com:443/umbraco
2018-02-19 12:09:01,631 [P10500/D13/T59] INFO Umbraco.Core.Sync.ApplicationUrlHelper - ApplicationUrl: https://www.thinix.com/umbraco (using web.routing/@umbracoApplicationUrl)
2018-02-19 12:09:02,146 [P10500/D13/T59] ERROR Umbraco.Core.UmbracoApplicationBase - An unhandled exception occurred
Here's the UmbracoTraceLog without an explicit URL set:
2018-02-19 11:00:02,761 [P10500/D2/T13] INFO Umbraco.Core.Sync.ApplicationUrlHelper - New ApplicationUrl detected: https://www.thinix.com:443/umbraco
2018-02-19 11:00:02,761 [P10500/D2/T8] INFO Umbraco.Core.Sync.ApplicationUrlHelper - New ApplicationUrl detected: https://www.rdiworks.com:443/umbraco
2018-02-19 11:00:02,763 [P10500/D2/T13] INFO Umbraco.Core.Sync.ApplicationUrlHelper - ApplicationUrl: https://www.thinix.com:443/umbraco (UmbracoModule request)
2018-02-19 11:00:02,763 [P10500/D2/T8] INFO Umbraco.Core.Sync.ApplicationUrlHelper - ApplicationUrl: https://www.rdiworks.com:443/umbraco (UmbracoModule request)
2018-02-19 11:00:03,027 [P10500/D2/T12] INFO Umbraco.Core.Sync.ApplicationUrlHelper - New ApplicationUrl detected: https://www.istatus.com:443/umbraco
2018-02-19 11:00:03,028 [P10500/D2/T12] INFO Umbraco.Core.Sync.ApplicationUrlHelper - ApplicationUrl: https://www.istatus.com:443/umbraco (UmbracoModule request)
Questions I have:
Does this constant flip-flopping of the ApplicationUrl have any performance impact?
Is this an issue I should care about?
If it does have a negative impact, is there a way to apply configuration file transformations to umbracoSettings.config for my staging and production environments (same way I do for web.config) so that I can specify explicit URLs for both environments?
I'm seeing this on 7.7.13 and it's causing issues.
I've just sent a new user invite and instead of providing a link back to the correct domain, the email generated by Umbraco sends the user to a totally irrelevant domain that just happens to have been pointed to that IP at some point. This then fails, as it's configured for SSL and therefore fails the cert check.
Is there any way we can turn off the auto detection of new URLs and just say "this/these are the ONLY domains Umbraco should ever listen on?"
Culture and hostnames is configured with only correct hosts.
umbracoServer table seems to only hold values which I would expect (actual domain and some dev/test ones).
I'm seeing entries in the log like this though, so Umbraco is clearly trying to do things with invalid domains -
2018-07-19 10:01:17,934 [P6964/D2/T62] ERROR Umbraco.Web.Scheduling.KeepAlive - Failed (at "https://www.invalid-domain.com:443/umbraco").
System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
I even have an ISAPI_Rewrite rule to attempt to stop them even hitting Umbraco, but I'm not convinced that's working -
Obviously, this isn't a perfect solution, but if you have ISAPI_Rewrite at your disposal, you can use the above, or convert it to whatever rewrite module you do have.
Early indications would suggest this is working and keeping my logs clear of requests for domains I don't want Umbraco to listen on.
Hopefully, it might point some people in the right direction.
And this happens on a dedicated server (not a shared server) where I'm in complete control of IIS and none of these bindings are added to the site or are bound to the server IP.
It probably needs an issue raising, but it's hard to reproduce.
I've just experienced this - the umbracoApplicationURL was blank and the site seems to have picked up a completely random domain ... only link seems to be it uses the same domain nameservers on my host!!!??
So, based on what Marc spotted in the source code it seems like Umbraco uses the server variable called SERVER_NAME to determine the host.
var url = "http" + ssl + "://" + request.ServerVariables["SERVER_NAME"] + port + IOHelper.ResolveUrl(SystemDirectories.Umbraco);
From what I've read this can be susceptible to spoofing by bots, which I'm guessing is what is happening. If a bot that is spoofing this happens to make the first request to the site then it will use the spoofed server name.
I saw some weirdness on client's site where the IIS server was picking up a weird domain that caused issues.
Setting the umbracoApplicationUrl in the umbracoSettings.config file did the trick - it was something along the lines of the server not finding a variable then picking up the first one it could find (which seemed to be from the request!!).
Thanks for the tip. I have updated the umbracoApplicationUrl on all our sites as I noticed it happening on all of them, but only the one has Uskinned licence.
Will keep an eye on things over the next few days and see how it behaves now.
Since setting the umbracoApplicationUrl in umbracoSettings.config there have been no more of the New ApplicationUrl detected logged against strange domains.
We will be setting that on all Umbraco sites we do from now on.
New ApplicationUrl detected frequently with Umbraco 7.8.1 Multiple Domains
We've got a single Umbraco instance running 7 Umbraco websites right now. I've recently upgraded to Umbraco 7.8.1 and in UmbracoTraceLog, I'm getting these log entries every time a URL is requested across all of our different websites.
My umbracoSettings.config with an explicit URL:
As you can see above, I've tried explicitly setting the umbracoApplicationUrl in umbracoSettings.config but that doesn't seem to help.
My umbracoSettings.config without an explicit URL:
Here's the UmbracoTraceLog without an explicit URL set:
Questions I have:
Best, Chris
I am experience the same issue as well after upgrade to 7.8.1. Before we were on 7.4.3 and there we didn't see this in the logs.
I as well wonder if this is something to care about?
Best, Martin
Bump
Bumping -- any ideas?
I am experiencing the same issue on Umbraco 7.10.4, any update?
Unfortunately never got this resolved; not sure if it's a problem or not.
I'm seeing this on 7.7.13 and it's causing issues.
I've just sent a new user invite and instead of providing a link back to the correct domain, the email generated by Umbraco sends the user to a totally irrelevant domain that just happens to have been pointed to that IP at some point. This then fails, as it's configured for SSL and therefore fails the cert check.
Is there any way we can turn off the auto detection of new URLs and just say "this/these are the ONLY domains Umbraco should ever listen on?"
Thanks
Adam
What have you got set up in your cultures and hostnames?
Do you see the url's in the umbracoServer table in the DB?
Hi Simon,
Culture and hostnames is configured with only correct hosts.
umbracoServer table seems to only hold values which I would expect (actual domain and some dev/test ones).
I'm seeing entries in the log like this though, so Umbraco is clearly trying to do things with invalid domains -
I even have an ISAPI_Rewrite rule to attempt to stop them even hitting Umbraco, but I'm not convinced that's working -
Actually, I think my ISAPI_Rewrite rule was wrong.
This might actually work -
The rule I had was in ISAPI_Rewrite 2 format, rather than 3, so my mistake.
I'll keep an eye on the logs and see if that stops the requests hitting Umbraco.
Obviously, this isn't a perfect solution, but if you have ISAPI_Rewrite at your disposal, you can use the above, or convert it to whatever rewrite module you do have.
Early indications would suggest this is working and keeping my logs clear of requests for domains I don't want Umbraco to listen on.
Hopefully, it might point some people in the right direction.
I am seeing this too in 7.12.3 and also domains that have nothing to do with this project.
Yep, I've seen this too. I've tweeted about this -> https://twitter.com/DanDiplo/status/1017469659216572416
And this happens on a dedicated server (not a shared server) where I'm in complete control of IIS and none of these bindings are added to the site or are bound to the server IP.
It probably needs an issue raising, but it's hard to reproduce.
Did you guys ever figure this out? I am encountering the same and have no clue how its solved for others...
I've just experienced this - the umbracoApplicationURL was blank and the site seems to have picked up a completely random domain ... only link seems to be it uses the same domain nameservers on my host!!!??
Steve
So, based on what Marc spotted in the source code it seems like Umbraco uses the server variable called
SERVER_NAME
to determine the host.var url = "http" + ssl + "://" + request.ServerVariables["SERVER_NAME"] + port + IOHelper.ResolveUrl(SystemDirectories.Umbraco);
From what I've read this can be susceptible to spoofing by bots, which I'm guessing is what is happening. If a bot that is spoofing this happens to make the first request to the site then it will use the spoofed server name.
A few references to this:
https://haacked.com/archive/2008/07/08/user-input-in-sheep-clothing.aspx/
https://expressionengine.com/blog/http-host-and-server-name-security-issues
http://yetanotherforum.net/forum/posts/t9073-SERVER-NAME-variable-may-not-work-as-expected
Good morning,
Was there ever a fix for this? It has just started to happen on one of our sites after changing to a dedicated IP so we could add an SSL cert.
These appears to be causing it end up giving an invalid licence message for the Uskinned theme we are using.
I see there is a workaround using ISAPI_Rewrite but am unsure how to add this, does to go into web.config somewhere?
Thanks, Mike
Hi Mike,
My (ISAPI_Rewrite) workaround from 2018 didn't seem to work in the end, and I didn't hear of any other suggestions.
I, rather annoyingly, just had to ignore it in the end.
Thanks
Adam
Thanks for the update, shame it didn't work.
Unfortunately it does seem to be causing is an issue for us, so I am trying to work out if there is anything I can do with a iis rewrite
Hi Mike,
I saw some weirdness on client's site where the IIS server was picking up a weird domain that caused issues.
Setting the umbracoApplicationUrl in the umbracoSettings.config file did the trick - it was something along the lines of the server not finding a variable then picking up the first one it could find (which seemed to be from the request!!).
HTH
Steve
Hi Steve,
Thanks for the tip. I have updated the umbracoApplicationUrl on all our sites as I noticed it happening on all of them, but only the one has Uskinned licence.
Will keep an eye on things over the next few days and see how it behaves now.
Just a quick update.
Since setting the umbracoApplicationUrl in umbracoSettings.config there have been no more of the New ApplicationUrl detected logged against strange domains.
We will be setting that on all Umbraco sites we do from now on.
Cheers
Really glad it helped.
Steve
is working on a reply...