Umbraco-CMS: V10 - Changing UmbracoPath in appsettings does not work

Which exact Umbraco version are you using? For example: 9.0.1 - don’t just write v9

10.0.0

Bug summary

In v9 you are able to change the Umbraco backend url using the UmbracoPath appsetting. In v10 you will get a blank page when you change the backend url. I think it has something to do with the new Umbraco.Cms.StaticAssets Razor library

Specifics

Chrome dev tools shows that the assets files are missing:

Steps to reproduce

Create a new umbraco site and install it as normal modify appsettings.json

{
  "Umbraco": {
    "CMS": {
      "Global": {
        "ReservedPaths": "~/app_plugins/,~/install/,~/mini-profiler-resources/,~/my-secret-backend/,",
        "UmbracoPath": "~/my-secret-backend",
        "IconsPath": "~/my-secret-backend/assets/icons"
      },
    }
  }
}

run website again goto https://localhost:44356/my-secret-backend

Expected result / actual result

Expect to see the Umbraco backend login page (like in v9) Actual result was a blank page

This item has been added to our backlog AB#20467

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 4
Comments: 30 (12 by maintainers)

Commits related to this issue

Alert people to the drop in support for UmbracoPath configuration in V10 If you are upgrading from V7/V8/V9 and have used the UmbracoPath property to rename your /Umbraco backoffice path, then it's s... — committed to marcemarc/UmbracoDocs by marcemarc a year ago

Most upvoted comments

I must agree with the majority in this thread. It’s a really bad idea to remove the option of using a customized url for backoffice.

It doesn’t matter that your approach is the best when considering security. You are completely neglecting User Experience.

With branding the whole user experience improves. It feels more personal to login to examplesite.com/personalUrl than examplesite.com/umbraco.

It also doesn’t matter if we (developers) agree with your approach. We mainly build solutions for less tech savvy people.

Restricting access by ip addess is not a realistic solution for many.

tedse1982 on Jun 12, 2023

@kjac I must agree with the guys above.

It’s not always about security, it’s more about branding, context and some corporate bs (from clients) if I must say … You have few cases here that explain why this should be a default feature (or available somehow) and I’m not going to repeat what has been said already, but I can add that most of the CMS Platforms out there allow you to change the admin or backoffice URL.

If there is a workaround in v10 (Great!), but in this case, I guess a lot of people will stop at that and never upgrade if this feature is never allowed, which will result on Umbraco implementers dropping in the future and migrating somewhere else with more freedom.

if this is a business decision from Umbraco to enforce its brand name upon the world, it needs to be revisited and look at how the digital world is changing to a more free internet instead of getting locked into a corporate bubble that won’t last.

The question we can ask you is if it’s time for us to look somewhere else if this feature is important to us?

TRexStark on Jan 5, 2023

i know you can do that (at least i know it now, but the choice was made in the past not to do this) and it is already deployed and used with the /umbraco/ part in the url 😉

Navorski on Sep 20, 2022

@Navorski thank you for reaching out and thank you for being so helpful with testing various solutions.

This issue has been discussed both internally and with some external stakeholders, and the consensus is that the feature should be removed entirely from Umbraco.

The recommendation is to apply IP restrictions or similar public access limitations to /umbraco. See this article for inspiration. The article is slightly outdated and is being rewritten for V10 (and not least for the removal of UmbracoPath as a configurable setting), but it is still relevant as-is.

I’m closing this issue now. Feel free to reach out if you have any questions 😄

kjac on Sep 20, 2022