Hi Halil, I'd like to use Claims-based security in my project because it is more universal than Roles-based. Particularly, Roles can be implemented as claims. With the current Abp.Core design, IPermissionChecker is based on Permission concept which can be identified by some string. To use claims (using my own implementation of IPermissionChecker), I'm using&parsing permissions in the form:
[AbpAuthorize("MyClaimType=MyClaimValue")] public MyResult MyAction(MyInput input) {...}
Unfortunately claims typically have long uri-based names (see System.Security.Claims.ClaimTypes standard .Net type) and it not convenient to have these names in an AbpAuthorizeAttribute. More convenient approach would be to extend AbpAuthorizeAttribute and permission checker such that it will be possible to write:
[AbpAuthorize(ClaimTypes.Role, "MyClaimValue")] public MyResult MyAction(MyInput input) {...}
What do you think?
-- Bogdan
Hi,
Wouldn't it be better to avoid server-side localization and do it only on a client side? IMO it will lead to a more modern&simple approach for web development and significantly improve speed because now pages will be simple HTMLs.
For instance, in angular, following code: <label>@L("ContactFullName")</label> can be rewritten as: <label>{{L("ContactFullName")}}</label> where L is a function on $rootScope. BTW, redefining L on a nested scope can be used for multi-language websites. And yet another benefit: changing '$rootScope.L' will change all relevant UI and will not cause bugs fixed by page reloading, as it is now.
Please note that I'm talking about best practice and not about removing razor-localization support because for many projects it may not be applicable. In general, I'm thinking about use case when razor&mvc are not used at all (only webapi and core asp.net). This kind of web apps may suffer from some limitations but are significantly easier to maintain, create and port.
-- Bogdan
Hi Halil, Any guidelines on adding new abp modules? I was thinking on adding functionality which will deliver Application/DTO metadata (properties, types, validation rules) to the client such that it will be easy to auto generate angular-ui-grid based list-pages and view/edit pages. It looks redundant to create CRUD UI manually over and over again.
Hi Halil,
It does not look like tenant concept is used in the sample and I cannot imagine simple enough project which can show benefits of this concept. Also descriptions of multi-tenancy which I was able to find in web are kind of blur. What about making it optional if there are no strong reasons to do otherwise. Maybe there is a need to have separate module for this?
BTW, great project. Thanks for ABP and let me know if you need any help.