V14-RC2: Login when hosting behind proxy

[enkelmedia]

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)

v14-RC2

Bug summary

I'm not sure this is a bug, it might also just be a configuration thing. I'm trying to run v14 using Visual Studio "Dev Tunnels" which is basically a reverse proxy and getting this errors.

Specifics

I'm getting this error:

error:invalid_request
error_description:The specified 'redirect_uri' is not valid for this client application.
error_uri:https://documentation.openiddict.com/errors/ID2043

I haven't looked at the code but I did try to configure this domain using "Culture and Hostnames" which did not seem to work.

Steps to reproduce

• Create new Umbraco instance
• Setup "Dev Tunnel" in Visual Studio
• Run application, to to /umbraco

Expected result / actual result

I'm not sure about how the internals work, the default should probably be to allow login from any configured domain (and maybe localhost and `.local.

In this particular scenario the exact URL to the dev tunnel might change over time so it would be nice to be able to allow wildcards *.euw.devtunnels.ms.

[github-actions]

Hi there @enkelmedia!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[bergmania]

Sounds like this is related to the BackOfficeApplicationManager.EnsureBackOfficeApplicationAsync(), where OpenIddict need to know where the backoffice is located.

On top of my head, i dont have a good solution to how this can be resolved when using reverse proxy.

[enkelmedia]

As far as I understand this any redirect URL has to be whitelisted when registering the OpenId Connect app with OpenDict.

Somewhere around here:

Umbraco-CMS/src/Umbraco.Cms.Api.Management/Security/BackOfficeApplicationManager.cs

Line 109 in d418802

CallbackUrl(_authorizeCallbackPathName),

Another scenario, that is supported in v13, that might be impacted here is if you host the same instance but on different hostnames (e.g. mysite.se, mysite.dk, mysite.com) and would like to allow access to the backoffice from mysite.se/umbraco, mysite.dk/umbraco and mysite.com/umbraco. In that case, a single backoffice URL is not enough.

Also, the default "thing" in Umbraco that figures out the current application URL could maybe take the X-Forward-For into consideration, that could probably solve the problem of running behind a proxy.

But I came to think about this, I solved this in v13 with a hack:

public class ProxyHostRewriteRule : Microsoft.AspNetCore.Rewrite.IRule
{
    public void ApplyRule(RewriteContext context)
    {
        context.Result = RuleResult.ContinueRules;

        // Get a reference to the current request
        HttpRequest request = context.HttpContext.Request;

        // Get the host from the header
        string? proxyHost = request.Headers["x-forwarded-host"];
        if (!string.IsNullOrWhiteSpace(proxyHost))
        {
            // Update the host
            request.Host = new HostString(proxyHost);
        }

        string? proxyScheme = request.Headers["x-forwarded-scheme"];
        if (!string.IsNullOrWhiteSpace(proxyScheme))
        {
            // Update the scheme (http/https)
            request.Scheme = proxyScheme;
        }

    }
}

Then during startup:

var rewriteOptions = new RewriteOptions();
rewriteOptions.Rules.Add(new ProxyHostRewriteRule());
app.UseRewriter(rewriteOptions);

I need to verify if this would solve the problem on v14, I'll keep you posted.

UPDATE: Yes, this hack works on v14 as well and makes it possible to run the app behind a reverse proxy (e.g Dev Tunnels).

Maybe the thing with mysite.se/umbraco, mysite.dk/umbraco and mysite.com/umbraco should be verified and posted as a different issue if it does not work.

[nikcio]

Hi,

I don't know if this is releated but I got this exact error when trying to boot from source code on the contrib branch. I added the following to access /umbraco

(This was on localhost I encountered the error)

[LennardF1989]

Heya! Got the same issue on the latest RC! We started out on https://localhost:8080 and have since moved to http://localhost:8080 and https://localhost:8443 - but when going to Umbraco, it will not accept the redirect_uri it creates (which points at https://localhost:8443/umbraco).

Most likely, this is due to the registration of the application when its first created, but we probably need a way to easily override this. Will investigate further.

EDIT: So, for one reason, restarting it a few times made it pick up the new URL eventually, not sure what happened there. Also, I've answered my own question, you can set BackOfficeHost in the security settings of appsettings.json to override the backoffice URL. This might also work for a reverse proxy situation as per OP.

[tobias-johansson-nltg]

I think we have the same issue.

We are logging our users in using their Microsoft accounts, that are managed from Azure (Entra Ids).
This worked fine in Umbraco 13, using the setup for OpenIdConnect described here.
When upgrading to Umbraco 14 this breaks, while still using the same Microsoft.AspNetCore.Authentication.OpenIdConnect version 8.0.6. This error occurrs when logging in:

So I tried to use Microsoft.AspNetCore.Authentication.MicrosoftAccount instead. It didn't get the iss error, but we instead got the error described in this issue:

Our setup is as follows:
We run Umbraco in Azure, with an Azure App Service. Let's say the address to the service is https://our-umbraco-instance.azurewebsites.net. The traffic goes in through Azure Front Door, which our external domain is connected to. Let's call the domain https://our-umbraco-instance.com. So the traffic goes like this:

User -> AFD (https://our-umbraco-instance.com) -> AAS (https://our-umbraco-instance.azurewebsites.net)

I have tried to understand where things go wrong, and these are my findings:
Running locally via https://localhost:<port> --> Works
Running locally with a local nginx proxy via https://my-machine --> Same error as in this issue
Accessing via AAS (https://our-umbraco-instance.azurewebsites.net) --> Works
Accessing via AFD (https://our-umbraco-instance.com) --> Same error as in this issue

As I said, this worked in Umbraco 13. What has changed, and what can we do to resolve the issue?

[HenrietteWalker]

Hi! Could you please provide any updates regarding this issue? Dennis from support suggested I reach out here for updates on this urgent issue. Thank you!

[AndersBrohus]

We have this happens on 14.0.0 - While hosting on a "normal" IIS setup :)

[bergmania]

Should be fixed by #16614

[tobias-johansson-nltg]

We get the same error after upgrading to 14.1.0-rc

[bergmania]

@tobias-johansson-nltg thanks for reporting, Ill take a look

[nikolajlauridsen]

Fixed in #16660 😄

[bergmania]

To use a proxy, it will be required to set the ApplicationUrl in config. The reason is, OpenIddict need to know where the requests will be coming from. The fix will be included in the 14.1 final or next RC, if we create one

[tobias-johansson-nltg]

To use a proxy, it will be required to set the ApplicationUrl in config. The reason is, OpenIddict need to know where the requests will be coming from. The fix will be included in the 14.1 final or next RC, if we create one

Thanks!
Will you have updated documentation of how to set the URL in config?

[bergmania]

To use a proxy, it will be required to set the ApplicationUrl in config. The reason is, OpenIddict need to know where the requests will be coming from. The fix will be included in the 14.1 final or next RC, if we create one

Thanks! Will you have updated documentation of how to set the URL in config?

We are reusing the existing config, that we recommend using in production anyway https://docs.umbraco.com/umbraco-cms/extending/health-check/guides/fixedapplicationurl

[enkelmedia]

Just adding to this, @bergmania - what if someone needs to access the backoffice from multiple different domains?

I think it would make sense to allow all configured domains in “Culture and hostnames”? Or at least provide some kind of extension point when the value is provided so that people can provide their own list of allowed redirects.

[david-tattan]

Hi, we are still having issues with the login screen and reverse proxies. We are using Azure Front Door, with a custom domain eg. https://my.custom.domain/

We can login successfully, but:
https://my.custom.domain/umbraco/management/api/v1/security/back-office/authorize?redirect_uri=......
returns a 302, and redirects to the default domain of the Azure Service App that is behind the Front Door:

On successful authentication, we are redirected back to https://my.custom.domain, so it is only on the openid authorization step that we see this issue right now.

We have added these configurations, with the values set to the custom domain of the Front Door:

Umbraco__CMS__Security__BackOfficeHost
Umbraco__CMS__WebRouting__UmbracoApplicationUrl

We've also tried adding an applicationHost.xdt file to allow HTTP_X_ORIGINAL_HOST and HTTP_HOST, but that didn't seem to change anything

[biapar]

#16741