P
Peter Judge
Guest
> I'm also not crazy about making the application's security dependent on a static CSV file that is tied more towards URL patterns in a particular order than actual back-end resources. There are use-cases for both URL-based and ABL-based authorization. I'd probably not remove the Spring-based authorisation since it's closer to the perimiter. The roles/rules may be provided by an authentication provider (like ldap), the resource server (the business logic code or db records or something else) or both. You can, in ABL, extract a user's roles from the asserted client-principal (ie those from the auth provider). The resource server roles will depend on the application and where they're stored. > I would like to find a way to provide the front-end with a list of resources and verbs that the currently logged-in user can run, so that the front end can correctly display valid options for the user. I’m not sure we want too much creativity in authorization … I think you should return what roles the current user has, after they're logged-in, and have the UI respond to that. The UI knows what roles it can react to; the user knows which roles they have. I'd think that's enough info to do the right thing in the UI. I thought there was more doc, but the KUIB follows this approach. There's some doc at community.progress.com/.../2939.how-to-implement-user-roles-in-kendo-ui-builder-2-1-with-an-openedge-backend .
Continue reading...
Continue reading...