Hey Rob!

Not sure if this is exactly what you're looking for, but there's a security setting for AuthCookieDomain that Umbraco uses to set the domain property on the cookie that it creates when folks log in.

I found a bit of info about these settings here: https://docs.umbraco.com/umbraco-cms/v/10.latest-lts/reference/configuration/securitysettings#auth-cookie-domain

And I think the domain gets set here: https://github.com/umbraco/Umbraco-CMS/blob/511ee96c9e0c54480b5350fa0bcabe693bdc1e0a/src/Umbraco.Web.BackOffice/Security/ConfigureBackOfficeCookieOptions.cs#L98

I'm admittedly not super familiar with the authentication flow for the Backoffice, but I played around with this setting on my local machine and was able to get it working so that I could authenticate successfully from the main site and the subdomain. Here's what my appsettings for Umbraco look like:

"Umbraco": { "CMS": { "Global": { "Id": "16ead1e2-295d-4bb6-a93b-f1848580bac6", "SanitizeTinyMce": true }, "Content": { "AllowEditInvariantFromNonDefault": true, "ContentVersionCleanupPolicy": { "EnableCleanup": true } }, "Security": { "AuthCookieDomain": ".example.com" } } }

Hope this helps!

Hi Allen,

I am also trying to get this working.

Thanks for the suggestion 🙂 When I update the AuthCookieDomain appsetting it seems to update the cookie domain set when I log into CMS backoffice as a CMS user rather than setting the cookie domain when logging into the website login as Umbraco member.

Was this the case for you or did it work for members too?

Thanks, Carole

Oops! I misunderstood originally and and mixed up users with members. Sorry about that, y'all. 🤦‍♂️

I tried this out again with a member account and some private content, and sure enough, I had the same result that Carole did. That AuthCookieDomain setting doesn't affect cookies for members the same way it does for Backoffice users.

Strangely enough, the code snippet Rob posted above seems to be working for me. When I log into my member account from the subdomain, my cookie has the subdomain listed, and when I log in via the root domain, the cookie has the root domain listed for the domain property. I might be setting things up locally in a way that doesn't accurately replicate the real-life scenario though. 😅

In case it's helpful at all, I did a bit more digging through the core code base and came across some comments around the way Member identity management is configured by default:

    // NOTE: We are using AddIdentity which is going to add all of the default AuthN/AuthZ configurations = OK!
    // This will also add all of the default identity services for our user/role types that we aren't overriding = OK!
    // If a developer wishes to use Umbraco Members with different AuthN/AuthZ values, like different cookie values
    // or authentication scheme's then they can call the default identity configuration methods like ConfigureApplicationCookie.
    // BUT ... if a developer wishes to use the default auth schemes for entirely separate purposes alongside Umbraco members,
    // then we'll probably have to change this and make it more flexible like how we do for Users. Which means booting up
    // identity here with the basics and registering all of our own custom services.
    // Since we are using the defaults in v8 (and below) for members, I think using the default for members now is OK!

Here's a link to that spot in the code for more context: https://github.com/umbraco/Umbraco-CMS/blob/511ee96c9e0c54480b5350fa0bcabe693bdc1e0a/src/Umbraco.Web.Common/DependencyInjection/UmbracoBuilder.MembersIdentity.cs#L33-L40

is working on a reply...