How to correctly login as Virtual User to use the Sitecore Content Editor? (Avoid Media Library Search redirects)

Question

I have a situation where I need to use VirtualLogin to enable a user to access the sitecore shell and use the Content Editor / Media Library editor.

This is the code for the Virtual Login (from many examples found around the Sitecore docs and blog posts):

using Sitecore.Security.Authentication;
using Sitecore.Security.Accounts;

    ...
    User virtualUser = AuthenticationManager.BuildVirtualUser(@"sitecore\kam", true);
    virtualUser.Roles.Add(Role.FromName(@"sitecore\publisher"));
    virtualUser.Profile.IsAdministrator = true;
    virtualUser.Profile.Save();

    AuthenticationManager.LoginVirtualUser(virtualUser);
    ...

So the user logs in fine, is redirected to /sitecore/shell/Launchpad, but then I found that when the logged in user opens the Media Library, the page always redirects out to /sitecore/login.

After a bit of inspection of the Networks tab under Chrome dev tools, I can see that the page redirects after a request is sent to /Applications/Buckets/Services/Search.ashx endpoint.

The full uri with query params is this:

http://cm.host/sitecore/shell/Applications/Buckets/Services/Search.ashx?callback=jQuery11020018711424457148906_1520245242493&q%5B0%5D%5Btype%5D=text&q%5B0%5D%5Bvalue%5D=*&q%5B0%5D%5Boperation%5D=should&pageNumber=0&type=Query&pageSize=20&version=1&id=%7B3D6658D8-A0BF-4E75-B3E2-D050FABCF4E1%7D&indexName=&db=&_=1520245242494

So I now know that it's the Search tab of Media Library which is running the default query on page load. If I remove the Default bucket query field for Media Library item, the initial load doesn't redirect.

But I have no idea how to authorise this internal API call to the Item Buckets endpoint, as it always returns ({"Redirect":"/sitecore/login"}) for the VirtualUser, but returns a normal response for a regular logged in user.

I'm pretty sure it's not a permissions issue because I can set a breakpoint after the line of code where LoginVirtualUser is called, and with this:

var item = Sitecore.Context.Database.GetItem("/sitecore/Media Library");
var right = Sitecore.Security.AccessControl.AccessRight.FromName("item:read");
var access = Sitecore.Security.AccessControl.AuthorizationManager.GetAccess(item, virtualUser, right);

And I see that the user has AccessRight to read the item.

Things tried already:

• inspecting the virtualUser.Profile
• inspecting the virtualUser.RuntimeSettings (not really sure what this is for)
• manipulating the query params on the Search.ashx query
• assigning all standard sitecore roles to the virtual user
• looking around the Sitecore.Buckets.config file

Also, I think that the same session cookies from the logged in VirtualUser are being passed to the search query request:

So the only thing I can think is that some authorization parameters are not being transferred to the this API request, but I'm really not sure on the details of how this API is served.

Anyone have any experience with this? Or can find any documentation on the Sitecore.Buckets.config?

Answer 1

Received some help from Sitecore support and turns out there is a "loggedin" pipeline that gets called when logging in normally via /sitecore/login.

Starting this pipeline after the LoginVirtualUser() call, successfully authorises the client to access the Media Library Search bar:

private ActionResult VirtualLoginToSitecoreShell() {
    // set user properties and roles
    ...

    AuthenticationManager.LoginVirtualUser(virtualUser);

    // Make sure to start the Sitecore "loggedin" pipeline!
    LoggedInArgs loggedInArgs = new LoggedInArgs()
    {
        Username = username
        Persist = true
    };
    Assert.ResultNotNull(this.PipelineFactory.GetPipeline("loggedin"), "loggedin pipeline was not found")
        .Start(loggedInArgs);

    return Response.Redirect(Sitecore.Constants.SitecoreShellPath);
}

And you can see what the loggedin Sitecore pipeline calls from the Web.config under <loggedin argsType="Sitecore.Pipelines.LoggedIn.LoggedInArgs">.

Answer 2

If you would not be able to find solution how to do it with virtual user then you will be able to use this workaround:

1. Add some service user that will have enough rights to do required action

2. Use UserSwitcher to temporary switch context

       using (new UserSwitcher(someServiceUser))
       {
           //do your stuff
       }