Explicit ServerRole set to Subscriber, backoffice still allows content editing?

Questions
1

Am I missremembering but as some point did explicitly setting the server role to subscriber cause the backoffice to be readonly for content/media and display a message to that effect?

Not seeing it in a 13.4.1 loadbalanced installation.

2

No, it doesn’t, and to my knowledge never has.

The ServerRole is specific to keepalive, scheduled tasks and scheduled publishing. It doesn’t change how any other parts of Umbraco works.

You can run into problems if your backoffice instance isn’t also the “Scheduling server” but that doesn’t necessarily mean that you need to actually set the server role when Load-balancing. In some of our environments on Azure the CI/CD workflow we use means that automatic election Just Works™

1 Like
3

I must have been confusing it with runmodes

Though when in the docs you see

There are two server roles to be aware of for flexible load balancing:

SchedulingPublisher - The Umbraco instance usually used for backoffice access, responsible for running scheduled tasks.

Subscriber - A scalable instance that subscribes to content updates from the SchedulingPublisher server, not recommended to be used for backoffice access.

If it’s not recommended then with Umbraco these days I would expect to see the default being it’s not allowed.. and an extension point to allow those who really want to use a subscriber as a content editor have at it :slight_smile:

4

I get where you’re coming from, it would certainly be nice if there was a setting to put an instance in “frontend” or “backoffice” mode but that’s not a feature that Umbraco has (yet).

The complexity lies in the fact that load balancing is a cross-cutting concern and there’s no nice way to define how a backoffice instance vs a “frontend” (client, content, whatever you want to call it) instance should operate. Complicating this further is that Umbraco’s component parts may need to operate differently for different kinds of load balancing. e.g. NuCache, and Examine need to work in different ways depending on how file systems are configured.

SchedulingPublisher vs Subscriber is only really relevant to scheduling, so it doesn’t make sense that this setting on its own would make sweeping changes to how the app works - like making the backoffice (and presumably certain services etc.) read-only.

Now that load-balancing the backoffice is on the roadmap (for Q4 this year) I think that this will be a moot point.

1 Like
5

We drive those configs by environments.. as well as the serverRole setting.. so think that can be handled reasonably easily

image
image609Ă—375 5.54 KB

using Microsoft.AspNetCore.Hosting;
using Umbraco.Cms.Core.Sync;

namespace www.Extensions.LoadBalancing
{
    public class SetServerRegistrarRoles : IServerRoleAccessor
    {
        private readonly IWebHostEnvironment _env;

        public SetServerRegistrarRoles(IWebHostEnvironment env)
        {
            _env = env;
        }

        public ServerRole CurrentServerRole
        {
            get
            {
                return _env.EnvironmentName switch
                {
                    "Development" => ServerRole.Single,
                    "Production" or "Staging" or "Local.Publisher" => ServerRole.SchedulingPublisher,
                    _ => ServerRole.Subscriber,
                };
            }
        }
    }
}

but take your point, lots of other scenarios available. Though if SchedulingPublisher vs Subscriber is only really relevant to scheduling or only intended to be.. then should there be some other setting for backoffice vs webheads… serverRole seems to semantically describe that.. and then we’re back to subscribers shouldn’t be able to save content) :slight_smile:

a load-balanced back office would be good, hopefully coinciding with when I can move from LTS 13 to 17!
I wonder if a conditional .AddBackOffice() only if scheduling publisher would break anything for a subscriber :thinking:

1 Like
6

Envs makes sense, we do something similar.

It totally does, though I think that’s a case of “naming things is hard” rather than having a broader meaning across the application - it sits in the Umbraco.Core.Sync namespace, which seems pretty tightly scoped.

Totally. IIRC the reason it’s recommended that subscribers don’t save content is that if the publishing instance is saving/publishing content, you can get locking and/or race conditions.

I don’t think you can do this, because you won’t be able to get the IServerRoleAccessor out of DI at boot?

EDIT:

.AddBackOffice() adds more than just strictly backoffice things. You don’t want to conditionally call this.

7

I was always under the impression that people deal with this by redirecting any /umbraco requests to the scheduling server so that no matter which frontend you’re on at least the editing will always happen on 1 backoffice instance. I can’t find this in the docs though.

Alternatively, instead of redirecting (which reveals where your scheduling server is) you could deny access to /umbraco and all subscribers.

8

That’s what I used to do, and it works fine, but it’s always felt like a workaround. I prefer treating the backoffice like a feature that can enabled or disabled on any given environment (irrespective of load balancing for that matter).

These days I do it like the below, which works well.

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

Where backofficeEnabled can be set based on an environment name or taken from config.

1 Like