[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

["Alexander Klimetschek (JIRA)" <ji...@apache.org>]

    [ 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:13 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 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}} => 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)