Authorization issue on locally hosted dev. environment

Questions
1

image
image1046×196 19.4 KB

Getting these errors, and an infinite loading indicator when trying to load backoffice through http via an ip. It works however over localhost. From what I understand, it’s because localhost is presumed trusted, thus these errors don’t show up.

We are on a development, internal environment, that has no hostname bindings, and due to this, we don’t even have a certificate on-hand.

We have tried a handful of things already to work around this issue:

  1. Trying to set options.DisableTransportSecurityRequirement to true, though unsure if this would only apply to Umbraco MCP.
  2. Setting UmbracoApplicationUrl and BackOfficeHost in appsettings
  3. Using app.UseForwardedHeaders(), app.UseHttpsRedirection(), and app.UseHsts().

We would like to be able to access this backoffice instance from any PC on our network over HTTP. We already have any of the specific logic for this in an if-block for IsDevelopment. Is there a way to disable the check causing this error for the dev. environment?

2

Hi,
This is probably hitting some middleware on the backend that assumes too much. I think you can draw some knowledge from this reply I gave earlier:

There are a few settings related to Backoffice authorization. I can’t get much meaning from your screenshot, as it just reports an HTTP error 400 on the /token endpoint. You would have to check the server logs for any meaningful messages.

One thing that stands out from your screenshot is that it looks like you might be on an older browser, based on the message “navigator.locks is not available - token refresh coordination disabled”. Could you please state which browser and OS you are seeing this on?

Hope this helps!

3

Hello Jacob,

Currently running the project through Visual Studio on Windows 11 version 10.0.26200 Build 26200, and the browser I’m currently using for this is Microsoft Edge Version 150.0.4078.65, which should be the latest official build. Current Umbraco version is 17.5.3.

From what I can tell, we only have one Middleware, and it’s rather barebones:

app.UseUmbracoCore();

app.UseUmbraco()
    .WithMiddleware(u =>
    {
        u.UseBackOffice();
        u.UseWebsite();
    })
    .WithEndpoints(u =>
    {
        u.UseBackOfficeEndpoints();
        u.UseWebsiteEndpoints();
    });

The specific response that is failing is the request to http://192.168.35.72:30645/umbraco/management/api/v1/security/back-office/token . It’s returning a 400 status code, and this is the response body:

{
  "error": "invalid_request",
  "error_description": "The specified HTTP method is not valid.",
  "error_uri": "https://documentation.openiddict.com/errors/ID2084"
}

I have set both UmbracoApplicationUrl and BackOfficeHost to http://192.168.35.72:30645, but am still having this issue.

Thanks,
Eric

4

Hi Eric,

Thanks for the details — that helped a lot, and I owe you a correction. The navigator.locks is not available warning wasn’t an old-browser issue as I first guessed; it was the actual clue. Edge treats http://192.168.35.72:30645 as an insecure context — unlike http://localhost, which browsers whitelist. In insecure contexts the browser removes certain APIs entirely, and one of them is crypto.subtle, which the login flow uses to compute the PKCE code challenge. That’s why the backoffice hangs before you ever get to log in.

The important bit: this is browser policy tied to the origin, so no combination of UmbracoApplicationUrl, BackOfficeHost, DisableTransportSecurityRequirement or middleware can fix it server-side — you did nothing wrong there. The 400 on /token (“The specified HTTP method is not valid”) is a secondary symptom: that endpoint only accepts POST, so it typically means the URL was opened directly in the address bar, or a redirect middleware turned the POST into a GET.

I’ve raised a fix here: Backoffice: Support running in insecure browser contexts (plain HTTP on IP addresses) - Pull Request #23426 - umbraco/Umbraco-CMS - GitHub — it makes login, preview and the clipboard features work in insecure contexts, hopefully landing in 17.6.

Until then, a few workarounds:

  1. In Edge/Chrome, open edge://flags/#unsafely-treat-insecure-origin-as-secure, add http://192.168.35.72:30645, and relaunch — the browser then treats that origin as secure and the backoffice should work as-is. Dev machines only, please.
  2. Tunnel to the machine so you can use localhost, e.g. ssh -L 30645:localhost:30645 [email protected], then browse http://localhost:30645.
  3. Give the machine a hostname and a dev certificate (mkcert makes this fairly painless) and run https properly.

Hope that unblocks you — and thanks for reporting it, this was a genuine gap on our side.