IIS redirects and new back office

[bjarnef]

In an Umbraco 13 project on Umbraco Cloud, we had a few IIS redirect rule, which has been working so for - also in combination with addons like Umbraco Deploy.

<rule name="Redirect umbraco.io to actual domain" stopProcessing="true">
	<match url=".*" />
	<conditions>
		<add input="{HTTP_HOST}" pattern="\.umbraco\.io$" />
		<add input="{HTTP_HOST}" pattern="^(dev|stage)(.*)?.euwest01.umbraco.io$" ignoreCase="true" negate="true" />
		<add input="{REQUEST_URI}" pattern="^/App_Plugins/" negate="true" />
		<add input="{REQUEST_URI}" pattern="^/umbraco" negate="true" />
		<add input="{REQUEST_URI}" pattern="^/sb" negate="true" /> <!-- Don't redirect Smidge Bundle -->
		<add input="{REQUEST_URI}" pattern="localhost" negate="true" />
	</conditions>
	<action type="Redirect" url="https://www.primo.com/{R:0}" appendQueryString="true" redirectType="Permanent" />
</rule>

<rule name="SEO - Remove trailing slash" stopProcessing="true">
	<match url="(.*)/+$" />
	<conditions>
		<add input="{REQUEST_URI}" pattern="^/umbraco" negate="true" />
		<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
		<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
	</conditions>
	<action type="Redirect" url="{R:1}" />
</rule>

<rule name="SEO - Convert to lower case" stopProcessing="true">
	<match url=".*[A-Z].*" ignoreCase="false" />
	<conditions>
		<add input="{REQUEST_URI}" pattern="^/umbraco" negate="true" />
		<add input="{REQUEST_URI}" pattern="^.*/install" negate="true" />
	</conditions>
	<action type="Redirect" url="{ToLower:{R:0}}" />
</rule>

<rule name="Redirect to www prefix" stopProcessing="true">
	<match url=".*" />
	<conditions>
		<!--<add input="{HTTP_HOST}" pattern="^www\." negate="true" />-->
		<add input="{HTTP_HOST}" pattern="^(www|da|no|se|fi|de|nl|pl|cn|us)(.*)" ignoreCase="true" negate="true" />
		<add input="{HTTP_HOST}" pattern=".*azurewebsites.net*" negate="true" ignoreCase="true" />
		<add input="{HTTP_HOST}" pattern="^localhost(:[0-9]+)?$" negate="true" />
		<add input="{HTTP_HOST}" pattern="\.umbraco\.io$" negate="true" />
	</conditions>
	<action type="Redirect" url="https://www.{HTTP_HOST}/{R:0}" />
</rule>

<rule name="HTTPS Redirect" stopProcessing="true">
	<match url="(.*)" />
	<conditions>
		<add input="{HTTPS}" pattern="^OFF$" />
	</conditions>
	<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" appendQueryString="false" />
</rule>

But after upgrading to Umbraco 17 something were wrong as part of Umbraco Deploy was missing. The dashboards were shown, but the actions to transfer and restore content were missing.

After talk with Umbraco support team, we noted the SEO redirect rules causes issues with redirecting the Umbraco backoffice modules at /umbraco/backoffice/

The documentation mainly mention to negate ^/umbraco:
https://docs.umbraco.com/umbraco-cloud/go-live/manage-hostnames/rewrites-on-cloud
https://docs.umbraco.com/umbraco-cms/develop-with-umbraco/application-code/backend-and-custom-logic/routing/iisrewriterules

I initially tried a new rule before SEO redirects suggested by AI:

<rule name="Skip Umbraco backoffice" stopProcessing="true">
  <match url=".*" />
  <conditions>
    <add input="{REQUEST_URI}" pattern="^/umbraco($|/.*)" />
  </conditions>
  <action type="None" />
</rule>

But it didn't quite seem to fix the issue and AI further mentioned:

You’re running into a classic IIS Rewrite gotcha: “stopProcessing” only stops rule evaluation for that request if the rule actually executes in the same rewrite phase — but Umbraco backoffice assets often get hit in a way where later rules still apply (especially when rules are evaluated in different stages or rewritten URLs re-enter the pipeline).

Also: your current rule uses action type="None", which is fine, but it does not guarantee a hard stop for subsequent rewrite rules that operate on rewritten paths or later conditions like {REQUEST_FILENAME}-based rules.

However a safer solution was to added the following to the redirects currently has ^/umbraco, which did solve the issue in this concrete project:

Yes. Right now you already exclude some /umbraco requests, but a few of these rules can still interfere with backoffice assets, APIs, previews, or installer routes depending on the exact URL shape.

The safest approach is to consistently exclude all backoffice traffic early in every SEO/redirect rule.

A robust pattern is:

<add input="{REQUEST_URI}" pattern="^/umbraco($|/.*)" negate="true" />

and an extended version including these:

<add input="{REQUEST_URI}" pattern="^/umbraco($|/.*)" negate="true" />
<add input="{REQUEST_URI}" pattern="^/install($|/.*)" negate="true" />
<add input="{REQUEST_URI}" pattern="^/App_Plugins($|/.*)" negate="true" />

[sofietoft]

Thanks for highlighting this @bjarnef !

I'm not entirely sure I understand what you're suggesting here.
Should we mention these patterns in our Cloud docs (https://docs.umbraco.com/umbraco-cloud/go-live/manage-hostnames/rewrites-on-cloud)?
Or do we need to update some of the existing redirect rules, because they are outdated?

[bjarnef]

Yes, while this worked in Umbraco 13 on Cloud with Deploy,

<add input="{REQUEST_URI}" pattern="^/umbraco" ignoreCase="true" negate="true" />

These rules had impact on Deploy transfer/restore actions:

<rule name="SEO - Remove trailing slash" stopProcessing="true">
	<match url="(.*)/+$" />
	<conditions>
		<add input="{REQUEST_URI}" pattern="^/umbraco" negate="true" />
		<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
		<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
	</conditions>
	<action type="Redirect" url="{R:1}" />
</rule>

<rule name="SEO - Convert to lower case" stopProcessing="true">
	<match url=".*[A-Z].*" ignoreCase="false" />
	<conditions>
		<add input="{REQUEST_URI}" pattern="^/umbraco($|/.*)" negate="true" />
		<add input="{REQUEST_URI}" pattern="^.*/install" negate="true" />
	</conditions>
	<action type="Redirect" url="{ToLower:{R:0}}" />
</rule>

After commenting these rules out, the Deploy actions shows up, but after futher investigation, I have updated rules to following and Deploy still shows transfer/restore actions:

<rule name="SEO - Remove trailing slash" stopProcessing="true">
	<match url="(.*)/+$" />
	<conditions>
		<add input="{REQUEST_URI}" pattern="^/umbraco" negate="true" />
		<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
		<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
	</conditions>
	<action type="Redirect" url="{R:1}" />
</rule>

<rule name="SEO - Convert to lower case" stopProcessing="true">
	<match url=".*[A-Z].*" ignoreCase="false" />
	<conditions>
		<add input="{REQUEST_URI}" pattern="^/umbraco($|/.*)" negate="true" />
		<add input="{REQUEST_URI}" pattern="^.*/install" negate="true" />
	</conditions>
	<action type="Redirect" url="{ToLower:{R:0}}" />
</rule>

[sofietoft]

So the correct way to negate the umbraco path in the "convert to lower case" rule, would be to use this pattern: ^/umbraco($|/.*).
Is that right? Or is it the "ToLower" part for the URL in the action that needs to be updated?
<action type="Redirect" url="{ToLower:{R:0}}" />

I'm not entirely sure I understand what exactly you think should be changed or added in our current docs.

[bjarnef]

It was mainly the change from:

<add input="{REQUEST_URI}" pattern="^/umbraco" negate="true" />

to this in the custom redirect rules:

<add input="{REQUEST_URI}" pattern="^/umbraco($|/.*)" negate="true" />

[sofietoft]

Ah, alright.
So the pattern negating the /umbraco path should change from ^/umbraco to ^/umbraco($|/.*).

I'll run it by our Cloud developer for confirmation, and look into updating our docs 🙏

[jemayn]

Hey @bjarnef

I am a bit confused with your findings, this pattern:

"^/umbraco"

means a path that starts with /umbraco - which means it matches anything after that.

Your pattern:

"^/umbraco($|/.*)"

means a path that starts with /umbraco, then has either end of line or / followed by any amount of characters.

That means your suggestion is less permissive, and would not allow for example /umbraco-deploy/whatever.

Do you happen to know the urls impacted by the full set of rewrite rules?

[bjarnef]

Hi @jemayn

Not quite sure how if has impact on Deploy, but we noticed redirect of Deploy module in index.js.
I can eventually invite you the project and I (and Umbraco support) could reproduce it on local environment when the redirects had "^/umbraco", but after changing to ^/umbraco($|/.*) (suggested by AI 🤖 ) it apparently works.