Virtual User causing error with AntiForgeryToken, The provided anti-forgery token was meant for user "extranet\user", but the current user is ""

Question

My site uses SSO for login so most site users do not have Sitecore accounts, as such when a user logs in a virtual user is created:

    protected void CreateVirtualUser(SSOCentralUser user)
    {
        // Create virtual user
        var virtualUser = AuthenticationManager.BuildVirtualUser($"extranet\\{user.PrimaryEmailAddress}", true);

        // Add user roles
        virtualUser = AssignRoles(virtualUser, user);

        // Update Profile
        virtualUser = SetProfile(virtualUser, user);

        // Login the virtual user
        AuthenticationManager.LoginVirtualUser(virtualUser);

        Sitecore.Diagnostics.Log.Info("Current User: " + Sitecore.Context.User, this);
    }

However, if the user logs in and then immediately navigates to the search page (which has @Html.AntiForgeryToken), this error is thrown: The provided anti-forgery token was meant for user "extranet\[email protected]", but the current user is "".

I have determined that this is because the virtual user is extranet\[email protected], but Sitecore.Context.User is Sitecore.Security.Accounts.User (which has no username). But, I don't know what to do about it.

If I load any page before I go to the search page, the error does not occur. I assume this is because when a page is loaded, it updates the antiforgerytoken so that when I then go to the search page the token matches Sitecore.Context.user, but I'm not sure. I expect that I could resolve the issue by making the page refresh via javascript after login, but that would not be a good user experience. Is there a way I can set Sitecore.Context.User to the virtual username, extranet\[email protected], or update the antiforgerytoken in my login code to match Sitecore.Context.User?

Answer 1

There several ways to address this issue, for example you can turn off the user check in anti forgery but this would make the site significant less secure or reload through javascript which provides a poor user experience as you already mentioned.

I think the key here is that a cross site request forgery attack targets a state changing operation, e.g. transferring money to a different account, changing a password etc. It sounds like the search page does not fall into this category, therefore I would turn off anti forgery here as there is no risk for an anti forgery attack.