I don't think we are all that far off from each other.
1. Each resource provider, if it supports security, should be responsible for
security
2. There should be a common interface to tell a resource provider what
permissions to be set.
3. I should be able to take a resource and if I have the privilege, determine
what permission restrictions are in force. This should work no matter what the
resource provider is.
And where I feel I'm really differing from others:
4. The permissions should be reflected within the context of the resources that
the resource provider provides. Much like how the jcr resource provider stores
acl as a rep:policy node. If I tell the servlet resource provider to that only
admin can get to any servlets under /content/custom/servlets/ that when I'm
using a resource browser to go down that tree, the resource provider adds
something like /content/custom/servlets/sling:policy that defines what was set.
What I don't want as a user is to have multiple locations to check to determine
what restrictions are being set for a given path. What I don't want as a
developer is to have multiple classes to deal with so that I have to create
restrictions differently if a user asks me to set a restriction on a resource.
I want magic
{mock}
SlingSecurity security = resource.adaptTo(SlingSecurity);
security.grantRead("bob")
for (SecurityRules rule: security.appliedRules()){
print(rules.toString());
}
{/end}
which would produce
admin / all *
set by jcr resourceProvider
sling-scripting / denyAll * set by jcr
resourceProvider
generic-users /custom read * set by file
resourceProvider
bob /custom/path read * set by jasons
awesome customResourceProvider
Where I have a problem with Radu's original suggestion is that the permissions
are defined in a separate tree, I would have less of a problem with this, if
the resource providers checked this tree and echoed them out, or if multiple
resource providers used this tree as a common store of permissions. I don't
care so much then. I'm more concerned about the experience and the interface.
- Jason
On Fri, Oct 5, 2018, at 12:52 AM, Carsten Ziegeler wrote:
> Well, this will be a fun discussion :) Adding security on top of
> something is usually easier to be bypassed than having security built-in.
>
> But I would like to get briefly back to the use case of this "dangerous
> servlet". Why isn't that servlet doing the permission checks which I
> think is way safer than relying on additional magic somewhere else
> (regardless of what it is)?
>
> Regards
> Carsten
>
