[
https://issues.apache.org/jira/browse/SLING-12794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17953134#comment-17953134
]
Achim Koch commented on SLING-12794:
------------------------------------
Here is some more context:
We can protect resources from public access by either:
* requiring authentication (aka "login")
* adding a privilege requirement (normal ACLs or CUGs)
* both (the latter implies the former)
As Angela pointed out, an authentication requirement can be defined by either
* an Authentication Handler registering the path or ancestor path
* a mixin 'granite:AuthenticationRequired' on the path or ancestor path
Requiring authentication (only) means a user just needs to have an account and
is logged in. No membership in a CUG or ACL is required. Note: These resources
are _not_ public.
Sling evaluates the authentication requirement, when it is evaluated
{_}in-line{_}: That means in the request and on the requested resource.
But we have identified 2 (+1) occasions where this needs to be evaluated
_out-of-line:_
*1. Servlet filter for cache control header*
When Sling is used with a (CDN) cache, we need to set a "no-cache" header on
protected resources. The normal way is to provide a servlet filter, that checks
if the resource is protected, i.e. requires a login (see above). In this case,
we do have the resource associated with the current request, and we have a user
session.
At the point the Servlet Filter is invoked, we have passed a (potential) login
already. But we can't determine, if a) the resource was public or b) the
resource required authentication.
Note: Assuming that the user has a personalized session is not an indicator.
The user could be logged in - but then opened a public page - which can be
cached.
A method like 'requiresAuthentication(Resource resource)' would help to decide
whether to set "no-cache" headers.
*2. Permission sensitive caching*
The AEM dispatcher can cache protected resources. But before delivering, it
would ask the publish, if that is allowed. Here the Publish is in the loop for
authentication / permission checking - but we could save expensive rendering
time.
The Dispatcher protocol goes sth like this:
Dispatcher -> Publish: HEAD /bin/permissioncheck?uri=/path/to/resource
Publish -> Dispatcher : 200 | 404 | 403
The servlet /bin/permissioncheck needs to be implemented on a per-project base.
This is to support custom permissions that are not based on JCR privileges.
In case we do use the bare Authentication Requirement to grant/deny access, the
/bin/permissioncheck needs a way to figure out if some case of authn req is in
place on that resource - which we can't.
The same method 'requiresAuthentication(Resource resource)' would help to
decide whether to set "no-cache" headers. A bit more convenient would be
requiresAuthentication(String uri). (uri = path)
Note: This also means, that requiresAuthentication() is executed with minimal
footprint and latency, because this would always bypass the cache.
*3. Marking protected links*
We have a public page with an href to a protected page. We want to mark all
links to a protected page with a lock symbol, e.g. "{+}Download Pricelist 🔒{+}"
to indicate, the link might require a login.
Here we would write a LinkTransformer, that automatically resolves the target
resources and determines its "status" (authn required | authz required |
public) and conditionally renders the lock symbol.
The same method 'requiresAuthentication(Resource resource)' would help to
decide whether to set "no-cache" headers. A bit more convenient would be
requiresAuthentication(String uri). (uri = path)
Note:
Of course, requiresAuthentication() would be used in conjunction with checking
for permissions. Though this seems to already be available in the public Sling
API (e.g. via checkPermission());
> Introduce API to check existing authentication requirements by path
> -------------------------------------------------------------------
>
> Key: SLING-12794
> URL: https://issues.apache.org/jira/browse/SLING-12794
> Project: Sling
> Issue Type: Improvement
> Components: Authentication
> Reporter: Angela Schreiber
> Priority: Major
>
> I got asked by Achim Koch about the ability to check if for a given path
> authentication requirements have been configured (either through service
> registration or through mixin type 'granite:AuthenticationRequired' placed on
> nodes).
> as far as I know this capability is currently not available which results in
> customers relying on implementation details.
> the request is to offer a public API that allows to check if for a given path
> there exists any authentication requirement with optional flag to check for -
> or +.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
