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

seems like I get the "internal error message" only then, if my localisation does not work - odd

Ok, works (by throwing any of the build in exceptinons) But is there a reason, why AbpAuthorizationException("messagetext") results in a generic message as "Internal server error" instead of "messagetext".

I get what I want, though, if I use UserFriendlyException()

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:"--

OK, looks promising. Does this work as the fileDto stuff worked.

Basically: If I use a HTML audio element, it does do it's own request, leaving out the bearer token. So I cannot use authenticated api entpoints for the audio src URL.

Does this help me here?

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?

I tried exactly this.

• Created a totally new Application with Anular, EF and integrated Identity-Server, no Mobile etc.
• Copied over the aspnet-core/.suite/entites folder, re-started abp suite and then tried to re-generate the previously defined entities with UI (angular)
• Still, no angular files are showing up in the git commit listing. Or can be seen in the angular/* folder.

Once you read this, you will have received my .suite/entites dir by e-Mail.

Thanks for finding out

Sorry but I dissagree. I have exactly this setup. Project + Projects. But my difference is, I use AuditedEnity instead of FullyAuditedAgregateRoot. I suspect you use a different template in this case ?!

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!

I want to hook into this issue, too. Because on my instance it also does just generate the Backend files but not the angular files. Configuration is the same (Angular, EF, v4.3.2)

What I have done which may prevent this from working is

• I renamed the aspnet-core folder to something elese.
• So in effect it lokks now as:
• Src
  • angular (...package.json...)
  • MyAppName (*.sln)

when I use abp suite I have first pointet it to ...\Src\MyAppName, but a second try was done to \Src. Both worked for backend gen. not for angular.