[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15826728#comment-15826728
]
Alexander Klimetschek edited comment on SLING-6187 at 1/17/17 8:14 PM:
-----------------------------------------------------------------------
Thanks [~justinedelson]. AFAICS, the patch [^SLING-6187c.diff] looks at all
@Suffixes, thus breaking any cases where someone would legitimately try to
create a {{foo@Suffix}} property in JCR. As [mentioned
above|#comment-15746876], we can make it a bit more selective by only checking
for suffixes where there is an according parameter without the suffix:
* {{foo}} and {{foo@Suffix}} in parameters => do the validation
* {{foo@Suffix}} only => skip
I was also thinking of post processors to indicate their suffix(es) in a
service property and have the post servlet check for it explicitly. However,
checking the modification list at the end as in your patch could work as well.
Not sure if existing post processors would typically remove the @Suffix entries
from the change list - if not, it would fail.
The other alternative to avoid any backwards compatibility issues (at the cost
of changing the request signature for the affected clients of the encryption
use case or any other that wants to benefit from this new validation) would be
to come up with something distinctively different, say {{@@@Suffix}}.
was (Author: alexander.klimetschek):
Thanks [~justinedelson]. AFAICS, the patch [^SLING-6187c.diff] looks at all
@Suffixes, thus breaking any cases where someone would legitimately try to
create a {{foo@Suffix}} property in JCR. As [mentioned
above|#comment-15746876], we can make it a bit more selective by only checking
for suffixes where there is an according parameter without the suffix:
* {{foo}} and {{foo@Suffix}} in parameters => do the validation
* {{foo@Suffix}} only => skip
I was also thinking of post processors to indicate their suffix(es) in a
service property and have the post servlet check for it explicitly. However,
checking the modification list could work as well. Not sure if existing post
processors would typically remove the @Suffix entries from the change list - if
not, it would fail.
The other alternative to avoid any backwards compatibility issues (at the cost
of changing the request signature for the affected clients of the encryption
use case or any other that wants to benefit from this new validation) would be
to come up with something distinctively different, say {{@@@Suffix}}.
> Provide a way for a POST request to assert a set of required
> SlingPostProcessors
> --------------------------------------------------------------------------------
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
> Reporter: Justin Edelson
> Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187c.diff, SLING-6187.patch,
> SLING-6187-profile.diff, SLING-6187-profile.diff, SLING-6187-validating.diff
>
>
> I would like to add support for a new "special" request parameter understood
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter
> may contain a comma-delimited list of names (see below) which *must* be
> available *at the time the request is processed* in order for the request to
> be handled. Whether or not those processors _do_ anything or whether the
> request succeeds or not is a separate question; this is just a preflight
> check if you will.
> If any of the required SlingPostProcessors are not available, the request
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service
> registration property {{postProcessor.name}} and default to the simple name
> of the SlingPostProcessor's implementation class if that property is not
> defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
