Hi Radu, Technically, my solution does have all the configuration in a central place. That being the web console where the OSGi service configurations can be viewed, modified, added and deleted by admin.
And I don't have to worry about securing read/write/delete access your new proposed security nodes. Regards, Eric On Thu, Oct 4, 2018, 4:45 AM Radu Cotescu <[email protected]> wrote: > Hi Eric, > > > On 3 Oct 2018, at 20:50, Eric Norman <[email protected]> wrote: > > > > 1. To handle POST requests, each servlet does it's own access checking in > > java code to ensure the right privileges are granted before any > processing > > happens. > > > > 2. To handle GET requests I utilize two generic filters whose > configuration > > is supplied by other multiple "config" OSGi services: > > a) SelectorWhitelistFilter - block access to any unexpected selectors. > A > > SelectorWhitelist configuration OSGi service is registered for each > > resource type to declare which selectors are allowed for each resource > type. > > b) BlockNotAuthorizedFilter - for selectors that get past #1, check > > permissions and block access for users who don't have the required > > privileges. A NotAuthorized OSGi service is registered for each family > of > > scripts to do the appropriate checks. > > I like both ideas, but I’d like to have something generic in Sling where > one can control the whole execution privileges schema from a central place, > which ideally wouldn’t imply any code to be written, just configuration. > > I think I could easily add method + selector combinations into the model I > was proposing. > > Thanks for the hints! > > Regards, > Radu
