On the home page of his website on the slider there is person with headphone I thought that that was our Venkat sir. But in my dream i have seen another person. But i can't remember his face exactly and how he was look like.
Can you re-use Handlers for different Requirements? Say you have an "AdminHandler" that you use to determine who is an Admin. So you use that to handle a GetIntoArea1Requirement. But there is another Requirement GetIntoArea2Requirement that both Admin and another group can see - so you have to write another handler for the 'another group' - but is there a way to re-use the Admin Handler or do you have to write the same logic again as it pertains to a different Requirement??
One way of achieving this is to make the SuperAdminHandler take the type IAuthorizationRequirement rather then the specific type done here. like so: public class SuperAdminHandler : AuthorizationHandler { protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, IAuthorizationRequirement requirement) { if (context.User.IsInRole("Super Admin")) { context.Succeed(requirement); } return Task.CompletedTask; } } this way once the service has been added for this handler it will run on all defined policies in the AddAuthorization methos and automatically allow superadmin access to future policies created there too. i am new to this so i have no idea if this is the recommended approach but it seems to work nicely. one thing to note is that this method doesnt help if you want to reuse something for specific requirements and not all... only way i can think of to acheive this would be to create a type like so: public class AllowSuperAdminRequirement : IAuthorizationRequirement { } then have your superadmin handler dirive from this type like so: public class SuperAdminHandler : AuthorizationHandler { protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, AllowSuperAdminRequirement requirement) { if (context.User.IsInRole("Super Admin")) { context.Succeed(requirement); } return Task.CompletedTask; } } then any requirements you want to use the superadminhandler too would inherit from AllowSuperAdminRequirement not IAuthorizationRequirement. like so: public class ManageAdminRolesAndClaimsRequirement : AllowSuperAdminRequirement { } this way any requirements created that inherit from AllowSuperAdminRequirement will be subject to the SuperAdminHandler again i am pritty new to this so would appreciate peoples feedback on this solution.
Since the SuperAdminHandler is somewhat generic and I could see it being reused elsewhere, do we need to specify that it inherits AuthorizationHandler. I see that it ties the handler to that requirement. But instead can change it to SuperAdminRequirement and add the requirement to the needed policy definitions?
Hello Nick - Yes, that's another great option. These custom requirements and handlers are very flexible and powerful. Depending on our application specific authorization requirements we design as we see fit. Hope this answers your question.
I am getting following error An unhandled exception occurred while processing the request. InvalidOperationException: No authenticationScheme was specified, and there was no DefaultChallengeScheme found. Microsoft.AspNetCore.Authentication.AuthenticationService.ChallengeAsync(HttpContext context, string scheme, AuthenticationProperties properties) Stack InvalidOperationException: No authenticationScheme was specified, and there was no DefaultChallengeScheme found. Microsoft.AspNetCore.Authentication.AuthenticationService.ChallengeAsync(HttpContext context, string scheme, AuthenticationProperties properties) Microsoft.AspNetCore.Mvc.ChallengeResult.ExecuteResultAsync(ActionContext context) Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeResultAsync(IActionResult result) Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeAlwaysRunResultFilters() Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeFilterPipelineAsync() Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeAsync() Microsoft.AspNetCore.Builder.RouterMiddleware.Invoke(HttpContext httpContext) Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context) Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware.Invoke(HttpContext context) Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)
Hi Venkat, context.Resource as AuthorizationFilterContext is coming as null, even it is decorated with [Authorize(Policy="EditRolePolicy") and I have also injected CanEditOnlyOtherAdminRolesAndClaimsHandler in the service. Any idea why is giving null?
Hi Vaseem, It's very old technology and mostly companies are using new one so may be it's not possible to upload by sir. you can visit other links to read vb.net.
In SuperAdminHandler, I placed a breakpoint to see whats going on For super admins, the if condition does return true and the context.succeed is also run but for some reason it doesn't let the resource be accessed even though it succeeded. HasSucceeded property is still false even though im calling the succeed method on the context. I googled this and i didnt find any solutions. This behavior persists only if im logged in as a super admin. This doesn't happen with admins. the context.succeed works for admins but not for super admin accounts. Any idea why? thanks.
How the Manage option is coming in test@pragimtech.com when the user is not in Admin role???? Because in the _Layout view the condition for showing Manage option is if the user is in Admin role. please help @kudvenkat
Very sorry, I don't have source code in the form of a download. However, you can find the source code in Text format on our blog at the following link. Instead of typing everything by hand, you can copy and paste. Hope this helps to some extent. www.pragimtech.com/courses/asp-net-core-mvc-tutorial-for-beginners/
I would like to clarify with you why are we seeing the "Access Denied" view when we logged in as SuperAdmin@pragimtech.com, edit the user pragim@pragimtech.com and click the Manage Roles button ??? And, after we have registered the second handler (SuperAdminHandler), why we are allowed access ???
Dear sir, I don't know, It is possible to see you or not... But tonight I have seen you in my dream .
Wow, How he looks like.
On the home page of his website on the slider there is person with headphone I thought that that was our Venkat sir. But in my dream i have seen another person. But i can't remember his face exactly and how he was look like.
Can you re-use Handlers for different Requirements? Say you have an "AdminHandler" that you use to determine who is an Admin. So you use that to handle a GetIntoArea1Requirement. But there is another Requirement GetIntoArea2Requirement that both Admin and another group can see - so you have to write another handler for the 'another group' - but is there a way to re-use the Admin Handler or do you have to write the same logic again as it pertains to a different Requirement??
One way of achieving this is to make the SuperAdminHandler take the type IAuthorizationRequirement rather then the specific type done here.
like so:
public class SuperAdminHandler : AuthorizationHandler
{
protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, IAuthorizationRequirement requirement)
{
if (context.User.IsInRole("Super Admin"))
{
context.Succeed(requirement);
}
return Task.CompletedTask;
}
}
this way once the service has been added for this handler it will run on all defined policies in the AddAuthorization methos and automatically allow superadmin access to future policies created there too.
i am new to this so i have no idea if this is the recommended approach but it seems to work nicely.
one thing to note is that this method doesnt help if you want to reuse something for specific requirements and not all...
only way i can think of to acheive this would be to create a type
like so:
public class AllowSuperAdminRequirement : IAuthorizationRequirement
{
}
then have your superadmin handler dirive from this type like so:
public class SuperAdminHandler : AuthorizationHandler
{
protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, AllowSuperAdminRequirement requirement)
{
if (context.User.IsInRole("Super Admin"))
{
context.Succeed(requirement);
}
return Task.CompletedTask;
}
}
then any requirements you want to use the superadminhandler too would inherit from AllowSuperAdminRequirement not IAuthorizationRequirement. like so:
public class ManageAdminRolesAndClaimsRequirement : AllowSuperAdminRequirement
{
}
this way any requirements created that inherit from AllowSuperAdminRequirement will be subject to the SuperAdminHandler
again i am pritty new to this so would appreciate peoples feedback on this solution.
Since the SuperAdminHandler is somewhat generic and I could see it being reused elsewhere, do we need to specify that it inherits AuthorizationHandler. I see that it ties the handler to that requirement. But instead can change it to SuperAdminRequirement and add the requirement to the needed policy definitions?
Hello Nick - Yes, that's another great option. These custom requirements and handlers are very flexible and powerful. Depending on our application specific authorization requirements we design as we see fit. Hope this answers your question.
Correct one .
Informative video
right
Hope you can do some tutorials on Asp.net Core with Razor Pages. Thanks!
Sure we will cover razor pages in a separate course. It's a great technology for building web applications.
@@Csharp-video-tutorialsBlogspot Thanks very much! We appreciate it!
I am getting following error
An unhandled exception occurred while processing the request.
InvalidOperationException: No authenticationScheme was specified, and there was no DefaultChallengeScheme found.
Microsoft.AspNetCore.Authentication.AuthenticationService.ChallengeAsync(HttpContext context, string scheme, AuthenticationProperties properties)
Stack
InvalidOperationException: No authenticationScheme was specified, and there was no DefaultChallengeScheme found.
Microsoft.AspNetCore.Authentication.AuthenticationService.ChallengeAsync(HttpContext context, string scheme, AuthenticationProperties properties)
Microsoft.AspNetCore.Mvc.ChallengeResult.ExecuteResultAsync(ActionContext context)
Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeResultAsync(IActionResult result)
Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeAlwaysRunResultFilters()
Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeFilterPipelineAsync()
Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeAsync()
Microsoft.AspNetCore.Builder.RouterMiddleware.Invoke(HttpContext httpContext)
Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware.Invoke(HttpContext context)
Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)
Hi Venkat, context.Resource as AuthorizationFilterContext is coming as null, even it is decorated with [Authorize(Policy="EditRolePolicy") and I have also injected CanEditOnlyOtherAdminRolesAndClaimsHandler in the service. Any idea why is giving null?
Thanks!
Hi..Sir, Can you Upload Vb.net video because i want to learn vb.net because your method is very nice to explaination..
Hi Vaseem, It's very old technology and mostly companies are using new one so may be it's not possible to upload by sir. you can visit other links to read vb.net.
@@technicalcrackedinterviews4392 Thanks a lot for reply..which language i should to learn in today's era...Sir
you can start with .net core directly with any DB like sql server
In SuperAdminHandler, I placed a breakpoint to see whats going on
For super admins, the if condition does return true and the context.succeed is also run but for some reason it doesn't let the resource be accessed even though it succeeded. HasSucceeded property is still false even though im calling the succeed method on the context. I googled this and i didnt find any solutions.
This behavior persists only if im logged in as a super admin. This doesn't happen with admins. the context.succeed works for admins but not for super admin accounts. Any idea why? thanks.
same here!
but in second superadmin handler you are allowing super admin to manage his own roles and claims.
How the Manage option is coming in test@pragimtech.com when the user is not in Admin role????
Because in the _Layout view the condition for showing Manage option is if the user is in Admin role.
please help @kudvenkat
How can we get the source code sir?
Very sorry, I don't have source code in the form of a download. However, you can find the source code in Text format on our blog at the following link. Instead of typing everything by hand, you can copy and paste. Hope this helps to some extent.
www.pragimtech.com/courses/asp-net-core-mvc-tutorial-for-beginners/
You can make source code by it self by practice it or from blog :)
Very confusing, not understand at all
I am sorry you are finding this confusing. Please let me know where you are getting confused, and I will try and clarify.
I would like to clarify with you why are we seeing the "Access Denied" view when we logged in as SuperAdmin@pragimtech.com, edit the user pragim@pragimtech.com and click the Manage Roles button ???
And, after we have registered the second handler (SuperAdminHandler), why we are allowed access ???