Hi.
It's not possible to check out. Because we've already upgraded.
In my opinion there shouldn't be any special custom code if using Redis: all permissions from all applications use the same permission cache, but they have own cache prefix, so the permissions are not mixed. And once I am done editing the roles, the cache has to be automatically updated, so when a user refreshes a webpage in app B, app C - he sees only the pages which are available according to the updated permissions. Unfortunately, it doesn't work...
Hi. Could you please let me know why this does not work anymore? Maybe it has something to do with the ABP version upgrade? If I remember it right, it was done for 4.x. Now we have ABP 5.1.3 and even though RabbitMq data seems to be correct, the permission update happens RANDOMLY, i.e. sometimes the permission with "false" value are not removed in fact from cache. Sometimes permissions with "true" value are not added... The question is related to SetManyAsync
. I've tried to use sync method instead, tried to use RefreshManyAsync
after SetManyAsync
, it's all in vain:
public class MyPermissionCacheRabbitMqReceiver : RabbitMqReceiverBase
{
private readonly IServiceProvider _serviceProvider;
public MyPermissionCacheRabbitMqReceiver(IServiceProvider serviceProvider, string queueName) : base(queueName)
{
_serviceProvider = serviceProvider;
}
public override async Task<object> Received(BasicDeliverEventArgs @event)
{
var permissionCacheRabbitMqEto = @event.ToDataObject<PermissionCacheRabbitMqEto>();
var permissionGrantCache = _serviceProvider.GetService<IDistributedCache<PermissionGrantCacheItem>>();
var currentTenant = _serviceProvider.GetService<ICurrentTenant>();
using (currentTenant.Change(permissionCacheRabbitMqEto.AbpTenantId))
{
await permissionGrantCache.SetManyAsync(
permissionCacheRabbitMqEto.Permissions.Select(permission =>
new KeyValuePair<string, PermissionGrantCacheItem>(permission.Key, new PermissionGrantCacheItem(permission.Value))));
}
return Task.FromResult<object>(null);
}
}
The service which sends the message resides on the different host and looks like this:
[Dependency(ReplaceServices = true)]
[ExposeServices(typeof(IPermissionAppService))]
public class ApiPermissionAppService : PermissionAppService
{
private readonly IRabbitMqManager _rabbitMqManager;
public ApiPermissionAppService
(
IPermissionManager permissionManager,
IPermissionDefinitionManager permissionDefinitionManager,
IOptions<PermissionManagementOptions> options,
ISimpleStateCheckerManager<PermissionDefinition> permissionStateManager,
IRabbitMqManager rabbitMqManager
)
: base(permissionManager, permissionDefinitionManager, options, permissionStateManager)
{
_rabbitMqManager = rabbitMqManager;
}
public override async Task UpdateAsync(string providerName, string providerKey, UpdatePermissionsDto input)
{
await base.UpdateAsync(providerName, providerKey, input);
var permissions = input.Permissions.Select(x => x)
.ToDictionary(x => PermissionGrantCacheItem.CalculateCacheKey(x.Name, providerName, providerKey), x => x.IsGranted);
await _rabbitMqManager.SendPermissionCacheChangeAsync("AbxEps-Abp-Caching", CurrentTenant.Id, permissions);
}
}
Sorry, we cannot share our code. Creating a test project would be too complex too.
UPDATE: I've tried to use Redis server cache instead of the built-in cache. And the problem remains. Do I ever need to make something special if I change role permission on separate app server A and want them to get applied on server B, server C...?
Your bot has closed these ticket again. How to prevent this?
Unfortunately, I cannot share the source code, but I'll try to describe what I've found out.
I've revealed that the issue happens when I am trying to modify HttpContext
response stream. I have to return custom JSON response when my application throws an exception. For this goal, the middleware has been created. It analyzes HttpContext
response headers and replaces this response stream - when an exception happens - with custom JSON response. The middleware uses IAuditingManager
to collect the information about errors.
Do you have any idea how modifying HttpContext
response stream may affect IAuditLogRepository
logic?
This issue can be reproduced when you are trying to save some error (the exception which happens in your application). Have you reproduced this case?
ABP Framework version: v5.1.2 UI type: Angular DB provider: EF Core Identity Server Separated (Angular)
Hello
I use the class implementing IAuditingStore
interface to catch all the errors in our application. I would like to use this class as a proxy: for this I inject ABP object implementing IAuditLogRepository
interface.
I've faced the issue while trying to save an error (It looks like task has been canceled by ABP logic) - see the picture attached:
This logic used to work well on the previous versions of ABP framework. What is wrong now?
Hi. Not exactly.
I use the RequiredPolicy
options for routing configuration of an application menu. It allows me to limit the displayed menu items based on user permissions. When a user tries to navigate to the page directly - he sees 403 error page. I would like to show information about a missing permission here. But HttpErrorResponse
object doesn't contain such information. I've made the research of JS code and found out that the inner logic doesn't include it for HttpErrorResponse
object. Please see the corresponding part of your source code below:
Hi.
We would like to add information about missing permission for an error page (403 Forbidden) in Angular application when a user uses direct link to some page. We tried to use HTTP_ERROR_HANDLER provider, but the HttpErrorResponse
object doesn't have any informations about missing permissions. Could you please extend this object or advice how we can get the information about missing permissions for a user?
First of all, the "MaxExceptionsLengthValue" property is missed in "Volo.Abp.AuditLogging.Domain.Shared" package version "5.1.2". Besides, you suggest me to make changes inside ABP module. Also, I've asked, "How exception can be truncated"? I don't want to change the length of DB field.
Hi.
I've read the thread which you advice. But this solution looks like a trick. Would be great if the logic was contained inside "Volo.Abp.AuditLogging" and there was no need to make external solution modifications. We use ABP framework for developing a lot of services. What will happen, when ABP team changes the logic and structure of AuditLog tables in some new release?
We would prefer to truncate an error message for AuditLog instead of changing the corresponding DB field size. What is a proper way of doing this?