I have read and tried a lot to establish resource based access policies. Basically the classic: Only ever the creation user may access a resource (for simplicity) In order to judge whether the current user can access a resouce, we have to get the Entity, first - hence enter the handler. So [Authoirize]-Attributse are not useful.
Keeping an eye on https://docs.microsoft.com/en-gb/aspnet/core/security/authorization/resourcebased?view=aspnetcore-5.0 I came up with this:
// create a policy based on claim audience
context.Services.AddAuthorization(options =>
{
options.AddPolicy("CallRecordingAccessPolicy", policy => policy.Requirements.Add(new CallRecordingPolicy()));
});
context.Services.AddSingleton<IAuthorizationHandler, CallRecordingAuthorizationHandler>();
If you're creating a bug/problem report, please include followings:
CallRecordingPolicy
being an empty class; "CallRecordingAccessPolicy" being never used anywhere else.
The implementation of the Handler is somewhat evident and the AppService is doing something like that:
public virtual async Task<CallRecordingDto> GetAsync(Guid id)
{
CallRecording recording = await _callRecordingRepository.GetAsync(id);
AuthorizationResult result = await AuthorizationService.AuthorizeAsync(resource: recording, requirement: new CallRecordingPolicy());
if (!result.Succeeded)
Essentially I use a lot of infrastructure with no real benefit. Also this is not right available in the DI container in the UnitTest. Testing is a bit cumbersome. And in fact I could just declare some other arbitrary class, hook it up to the DI-Container and use it as so:
public virtual async Task<CallRecordingDto> GetAsync(Guid id)
{
CallRecording recording = await _callRecordingRepository.GetAsync(id);
bool result = await _callRecordingChecker.CanAccess( recording _currentUser);
if (!result)
public class CallRecordingAuthorizationHandler : ITransientDependency
{
public Task<bool> CanAccess(CallRecording r, ICurrentUser cu)
So, why should I use the first approach over this second approach?
Advantage:
I have some problems getting the big picture of your design of Controllers, AppServices and the common Interface.
Let's take as a sample
interface IFooAppService
{
Task<FooDto> GetFooAsync(Guid id);
}
class FooAppService: IFooAppService {..}
class FooAppController: IFooAppService {..}
Maybe I have to solve the whole thing different. but lets considder my current situation:
In GetFooAsync()
I want to restrict access to the API. As in the ASP.Net samples I want to ensure the Author is the same as the user. Therefore I have to get the entity, first.
where would I actually do my check? Obviously in the AppService
because this is where I get my entity, first. (But ASP.Net Authorisation suggests to use the ClaimsPrincipal
. Therefore the Controller seems to be the place to write code:
Like so: var authorizationResult = await _authorizationService.AuthorizeAsync(User, Document, Operations.Read);
Consider the authorized check works like a snap. So, eventualy I have to branch with an if(authorized)
What would I do in the Forbidden case?
In good old Controller-Style I would return ForbidResult()
but due to the interface I cannot do that because the compiler does not let me return an ActionResult
, if my interface Result is a FooDto
should I change to Task<IActionResult>
?
will it have any implications with the proper serialisation and the API generation abp generate proxy
?
see https://docs.microsoft.com/en-gb/aspnet/core/security/authorization/resourcebased?view=aspnetcore-5.0
Hi,
what is abp.io's equivalend or logical follower to using FileController
and ITempFileCacheManager
?
Problem to solve: Use a file as download or in <img> or <audio> html tags where bearer-token cannot be supplied. Therefore putting some data from an authenticated API into temp storage, which can be then downloaded from a temp url for a certain time span.
Or is there any ohter solution to play an audio blob via an authenticated API?
If I use abp suite
to genreate me some new entities it also generates AppServices and interfaces.
I used for example 'Project' + 'Projects' (pl) but the generated files are as such:
ProjectAppService.cs
public class ProjectsAppService : ApplicationService, IProjectsAppService
IProjectAppService.cs
public interface IProjectsAppService : IApplicationService
This is inconsistend (regarding file name and first type in file) and stylecop wuld complain. (Plural vs. singular) I wonder if this causes me problems with abp suite in the future if I rename the files or classes.
But I appreciate this to be fixed as a bugfix in the first place!