Starts in:
1 DAY
18 HRS
47 MIN
15 SEC
Starts in:
1 D
18 H
47 M
15 S

Activities of "rkoepferl"

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:

  • Simple, thats waht needed
  • easier to use in UnitTests
  • more Straight forward
  • automatically in the DI container

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.

  1. 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);

  2. 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

  • ABP Framework version: v4.3.2
  • UI type: Angular
  • DB provider: EF Core
  • Tiered (MVC) or Identity Server Separated (Angular): no
  • Exception message and stack trace: --
  • Steps to reproduce the issue:"--

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!

Showing 1 to 4 of 4 entries
Made with ❤️ on ABP v9.1.0-preview. Updated on November 20, 2024, 13:06