Does anybody know why Umbraco (Cloud) sometimes thinks the URL is on one of the azurewebsites domains? The only "fix" we've been able to find is to restart the site, which is not great but also really not that bad. But the major issue is that when it happens — because the site is built with uSkinned SiteBuilder — the whole site screams "NO VALID LICENSE" everywhere - which is very unfortunate when the client has in fact paid a good chunk of money for a valid license. Is there a way to make sure this doesn't happen?

I was about to suggest you checking the UmbracoApplicationUrl setting, but apparently Cloud overrides this 🙂 https://docs.umbraco.com/umbraco-cms/reference/configuration/webroutingsettings

Yep - I saw that as well :)

That's not great.. :/ do you have a hostname configured on the root node though?

@Chriztian Steinmeier I don't think this is Umbraco cloud specific. We see it on sites hosted on Azure as well.

Yup - domains configured (one full hostname, the other just a

/en

path)

Which version of Umbraco?

It's Umbraco

v10.5.1

How do you see it? I.e., where is the

azureWebSites.net

URL appearing?

When I visit the site, it's rendering on the correct hostname - but all text is replaced with "NO VALID LICENSE" because uSkinned sees the wrong hostname (in the Backoffice). https://cdn.discordapp.com/attachments/1273927248218423367/1274002175722520586/uskinned-azure.png?ex=66c0aa7c&is=66bf58fc&hm=33f6780e9a72cafc12d7ef1ddfdd116c9daa43e32e9ee26c71e81092f73b7834&

Yep this is due to the license check only being executed once. If the internal (azure) url is called first (for example during warmup) and the license check is then executed, it results in an invalid license. This is also the case for Sitecore Forms.

Thanks @Maarten - that makes sense and explains (I guess) why it happens 👍 That I have to meddle with code to fix it is just sooo frustrating...

Just so I can relay this @Chriztian Steinmeier do you know if you would get the same error if the umbraco.io domain was triggered instead? So is the license strict and valid only for a single domain?

From the screenshot it seems like its licensed for *.(blurred).dk, *.(blurred).dk.local, *.euwest01.umbraco.io, and *.euwest01.umbraco.io.local

ah yes of course! not sure how the first ping to azurewebsites.net arrives, but it could be under Azure's control - have asked if we can do anything about it

If you have a health check on the app service, it will call a relative URL using the default domain.

Well it's Umbraco Cloud, so you don't have access to additional features like that. I just got an answer back from the team: our own licenses also suffer from this problem, and we can't solve it either (a middleware redirect might also be too late, as the URL might be initialized before it hits the redirect already). This is why our license engine requires you to specify a URL in the

umbracoApplicationUrl

and uses only that. It's good that the license already allows umbraco.io, but unfortunately it seems that it would require uSkinned to make a change in their domain checking code for this to work reliably.

Are you sure that your license engine uses the umbraciApplicationUrl? I've configured that but Forms still uses the first url it encountered. Which kind of makes sense as otherwise you can fool the enterire license check by passing in a localhost address.

Hi @Chriztian Steinmeier, Paul from uSkinned here. The issue is that you are accessing the site on a domain that hasn't been registered with your license. Looking at your screenshot your license is only registered for the blurred-out .dk domain and umbraco.io domain as well as localhost. All Umbraco Cloud sites have a default azurewebsites.net domain assigned to them too. Therefore, when you create a license following our guide (step 3 https://uskinned.net/support/how-to-create-download-and-activate-a-uskinned-license), we highlight that you should ensure both the umbraco.io and azurewebsites.net domains are present, as well as your primary/production domain(s). You can reach out to our team at any time here: https://portal.uskinned.net/contact — we're always happy to help! 🙂 Thanks!

Thanks @Paul Daly (uSkinned.net) — I have never seen those docs before (sorry!), but it's really great that they're there and that the problem can be solved in a simple manner 🙌 I've reached out to you and your team before and you've always been of great help. I was convinced that this was a Cloud bug, though (which is kind of is, and kind of isn't, if I understand all of the above comments correctly 😬). Thanks again 👍

You're welcome, @Chriztian Steinmeier!