[
https://issues.apache.org/jira/browse/SLING-6767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608508#comment-16608508
]
Eric Norman commented on SLING-6767:
------------------------------------
[~joerghoh] Well, I suppose the ambiguity about whether a specific bundle or
component is active at a given moment is the nature of an extensible modular
and dynamic architecture. I would personally not like to stuff this kind of
use-case specific functionality into the org.apache.sling.servlets.post bundle
just to be guaranteed that it is there.
In my opinion, at some point you will have to assume that whatever "gatekeeper"
component you chose to utilize has been installed and activated. And if you
want to customize the response for someone else's operation, then then a
SlingPostProcessor extension or a custom PostResponseCreator would be a
reasonable solution.
I guess the other problem I have is with the "caller can detect the difference"
part of your proposal. That kind of thinking is dangerously close to an
information disclosure security vulnerability. If the client can detect server
side configuration details then it can assist in refining an attack into the
system.
> Jackrabbit Usermanager: Allow to detect whether a POST request was treated by
> the default POST servlet or the jackrabbit.usermanager
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SLING-6767
> URL: https://issues.apache.org/jira/browse/SLING-6767
> Project: Sling
> Issue Type: Improvement
> Components: JCR
> Reporter: Konrad Windszus
> Priority: Major
> Fix For: JCR Jackrabbit User Manager 2.2.8
>
>
> Currently it is impossible to tell from the response whether a POST request
> has been answered by either the Default Sling POST servlet or the Jackrabbit
> Usermanager. Both the JSON and the HTML look exactly the same no matter, who
> answered. It should be possible to see from the client-side whether a request
> has been treated by one or the other.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)