Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at

  • Rob 2 posts 72 karma points
    Sep 19, 2023 @ 14:48

    Umbraco 10 - Set membership domain to allow subdomains

    Hi everyone,

    I'm having a problem setting Umbraco membership to allow subdomains. I have umbraco 10 running and have an API end point that logs the user in so that they can log in from subdomain sites. However, I can't find a way to change the cookie domain in the backend code to be "" to return the cookie to the subdomain where the user logged in from. I've tried various things, and this code is increasing the cookie lifespan but ignoring the domain for whatever reason:

    services.ConfigureApplicationCookie(options =>
        options.ExpireTimeSpan = TimeSpan.FromDays(365);
        options.Cookie.Domain = "";

    Any help with this would be greatly appreciated. Thanks,


  • Allen Smith 2 posts 72 karma points hq
    Sep 26, 2023 @ 16:34
    Allen Smith

    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:

    And I think the domain gets set here:

    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": "" } } }

    Hope this helps!

  • Carole Logan 17 posts 118 karma points MVP 8x c-trib
    Sep 26, 2023 @ 21:07
    Carole Logan

    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

  • Allen Smith 2 posts 72 karma points hq
    Sep 27, 2023 @ 05:01
    Allen Smith

    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:

Please Sign in or register to post replies

Write your reply to: