Try our conversational search powered by Generative AI!
AI OnAI Off
"Access was denied to content #. The source page in this Move operation requires access level "Read, Delete" which the current user does not have
When you run manually, the job uses your principal - which usually is the admin. When you run it automatically it will use either the anonymous principal, or the principal you assign to it. so the solution could be either
- use Move(contentLink, target, AccessLevel.NoAccess);
- assign a principal which has necessary access rights to the current principal at the beginning of your job, and assign it back when it's done.
Nov 14, 2023 7:23
eperezjr
- Nov 14, 2023 14:31
I tried doing this based on another job we have that's doing the same thing and this appears to be what other people are doing too:
if (HttpContext.Current == null)
{
PrincipalInfo.CurrentPrincipal = new GenericPrincipal(
new GenericIdentity("SchduledJobService"),
new[] { "Administrators" });
}
But I get the same error. Is there anything else I need to do to get it to work?
if (HttpContext.Current == null)
{
PrincipalInfo.CurrentPrincipal = new GenericPrincipal(
new GenericIdentity("SchduledJobService"),
new[] { "Administrators" });
}
But I get the same error. Is there anything else I need to do to get it to work?
Quan Mai
- Nov 14, 2023 15:19
maybe you can try to add the log to see at the point the job runs automatically, what Principal is used? Maybe HttpContext.Current is not null and your code was not excuted (it should be null in context of a scheduled job, but maybe some value was assigned )
eperezjr
- Nov 14, 2023 16:48
It does get set. I checked and confirmed Current was null and the CurrentPrincipal is set. I'm not entirely sure what is used for the group name. So I tried it with the Administrators name and our own CmsAdmins name. Same result both times. I get this locally. Would it be different on integration or any of the other deployed envs?
For the second option mentioned by Quan, you could add a dependency of IPrincipalAccessor in the constructor and then assign as below.
_principalAccessor.Principal = new GenericPrincipal(new GenericIdentity("RoleNameGoeshere"), null);
Nov 14, 2023 14:12
eperezjr
- Nov 14, 2023 14:53
I get the same error if I use Administrators or CmsAdmins, latter of which is what I see as the admin role name in our system. _principalAccessor.Principal = new GenericPrincipal(new GenericIdentity("CmsAdmins"), null);. I called this in the constructor.
Can you try this :
Based on the MS documentation, it looks like you also need to assign the principal to current thread https://learn.microsoft.com/en-us/dotnet/standard/security/how-to-create-genericprincipal-and-genericidentity-objects
var myPrincipal = new GenericPrincipal(new GenericIdentity("RoleNameGoeshere"), null);
_principalAccessor.Principal = myPrincipal
Thread.CurrentPrincipal = myPrincipal;
Nov 14, 2023 17:16
eperezjr
- Nov 14, 2023 17:56
Doesn't seem to have made a difference. The wild thing is that we have another job that uses:
if (HttpContext.Current == null)
{
PrincipalInfo.CurrentPrincipal = new GenericPrincipal (
new GenericIdentity("SchduledJobService"),
new[] { "Administrators" });
}
And it works. So I'm not sure what is different with this new job.
if (HttpContext.Current == null)
{
PrincipalInfo.CurrentPrincipal = new GenericPrincipal (
new GenericIdentity("SchduledJobService"),
new[] { "Administrators" });
}
And it works. So I'm not sure what is different with this new job.
I get this error when a job I created runs automatically. It works fine when I run it manually. The job creates and updates blocks. Do I need to do anything to set the permissions for whatever service account the job runs under?