Scheduled Job Elevated Permissions not working

Scott Reed

Vote:

I am trying to programatically work with commerce in a job, I have elevated the user of the job to be an admin (something we've done before in CMS many times) using

            if (HttpContext.Current == null)
            {
                PrincipalInfo.CurrentPrincipal = new GenericPrincipal
                (
                    new GenericIdentity("SchduledJobService"),
                    new[] { "Administrators" }
                );
            }

I'm try to use the IContentRepository service's delete method to delete a commerce item but I'm getting the error Access was denied to content 1073741827__CatalogContent. The required access level was "Administer"..

Is there something different in commerce, also we are using Episerver 10 ASP.NET Identity.

It's also worth noting if I don't elevate permissions and run it manually as my admin user it all works fine

#181879

Sep 01, 2017 13:55

David Knipe

Vote:

I've not tried it but it's likely you need to create a new generic identity and also a generic principal to ensure you can add the role claim. See this for more info:

https://docs.microsoft.com/en-us/dotnet/standard/security/how-to-create-genericprincipal-and-genericidentity-objects

Please do blog it if it works ;)

#181880

Sep 01, 2017 16:26

Scott Reed

Vote:

I think it's something commerce specific, I've tried this as I say this has usually worked for us without issue on CMS items. I've also tried actually creating a user with CMS Admin access and using the IUserImpersonation for the login and it still doesn't work.

#181881

Sep 01, 2017 17:06

Scott Reed

Vote:

I managed to get it working using the admin login and the IUserImpersonation service. I think maybe as there's an admin user in both CMS and Commerce it worked

            // This block allows for a scheduled job to perform content repository updates when ran on a schedule,
            // If the scheduled job is exectued manually, this block is ignored
            if (HttpContext.Current == null)
            {
                var imponationService = ServiceLocator.Current.GetInstance<IUserImpersonation>();
                var identity = imponationService.CreatePrincipal("admin");

                PrincipalInfo.CurrentPrincipal = identity;
            }

#181882

Sep 01, 2017 17:23

Scott Reed

Vote:

Spoke to soon that only worked when I ran it manually. Dammn, one for next week I think

#181883

Sep 01, 2017 17:30

Murtaza Ali

Vote:

Hi Scott Reed,

Try with existing/real user that is in the episerver system and with elevated access rights that will work.

we use the below code and xyz is real user in our system.

 if (HttpContext.Current == null)
            {
                PrincipalInfo.CurrentPrincipal = new GenericPrincipal(
                    new GenericIdentity("xyz"),
                    new[] { "Administrators" });
            }

Cheers

#181916

Edited, Sep 05, 2017 7:06

Scott Reed

Vote:

Thanks, I've tried this already. At the moment I'm just doing my own check and calling the CRUD APIs with the NoAccess flag

#181918

Sep 05, 2017 10:35

K Khan

Vote:

While running the job we are aware that it runs in the context of Logged In User.
While running in background, we have to specify Current Principal, that you are already doing
So problem is definitely somewhere else, try this

if(PrincipalInfo.CurrentPrincipal.Identity.Name == "*****")
{

//log user name to see which user is running thread
//Set the BypassAccessCheck to true for IContent, if using
//Call CRUD operations
}

#181925

Sep 05, 2017 14:42