Hi Wagner,
Thanks for clarifying, but this is quite a tricky implementation (of the attributes).
My first reaction was to take this as the attributes behave in a sort of AND fashion (i.e. both must be fulfilled). However, that doesn't explain why the TSecret entity works if user_role = 'admin' and TInvoiceItem doesn't for either user_role.
However, looking at this topic EntityAuthorizeScopes problem, it appears there must not be any overlap in permissions granted by the attributes. So for the TInvoiceItem entity user_role 'User' is also required for GET and LIST and therefore it doesn't work. In case of TSecret this is not required (GET/LIST not used for 'user') and therefore it works. Can you confirm this?
My intention (for a real-life application) was to control access rights by different levels of user_roles (e.g. user, poweruser, admin). With a single-value claim (as in this case 'user_role' containing a single value) that will become quite complex and error prone if my understanding above is now correct.
Based on above, below approach (using EntityAuthorizeScope with 'stacked' roles in scope) appears to work as desired and make things much easier to implement and therefore less error prone for my scenario.
Args.Token.Claims.AddOrSet('scope', 'email user');
if SameText(Args.User.UserName.Value, 'mark') then
Args.Token.Claims.AddOrSet('scope', 'user poweruser admin');
[Entity]
[EntityAuthorizeScopes('user,poweruser,admin', EntitySetPermissionsAll)]
[Table('Invoice')]
[Id('FID', TIdGenerator.Guid)]
TInvoice = class
....
[Entity]
[EntityAuthorizeScopes('user,poweruser,admin', EntitySetPermissionsRead)]
[EntityAuthorizeScopes('poweruser,admin', EntitySetPermissionsWrite)]
[Table('InvoiceItem')]
[Id('FID', TIdGenerator.Guid)]
TInvoiceItem = class
....
[Entity]
[EntityAuthorizeScopes('poweruser,admin', EntitySetPermissionsRead)]
[EntityAuthorizeScopes('admin', EntitySetPermissionsWrite)]
[Table('Secret')]
[Id('FID', TIdGenerator.Guid)]
TSecret = class
....
Or would you use a different approach for my scenario?