[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15826741#comment-15826741
]
Justin Edelson edited comment on SLING-6187 at 1/17/17 8:28 PM:
And at least for the {{@Encrypted}} case in AEM, the postfix is removed from
the modification list and I would expect that this is the required practice
since the {{foo@Postfix}} property is not actually "modified".
was (Author: justinedelson):
And at least for the {{@Encrypted}} case in AEM, the postfix is removed from
the modification list.
> 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)
[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746852#comment-15746852
]
Alexander Klimetschek edited comment on SLING-6187 at 12/14/16 1:26 AM:
My view now is that a post processor that relies on the @Suffix mechanism where
the properties would be written differently, without failure, if the processor
is not active, is a problem of the processor. And slightly so for Sling
encouraging this fragile approach. The Sling Post servlet should have a
mechanism like I outlined above that gives a clear behavior, without a default
behavior fallback, without any implementation specific references the client
has to know about.
Why should an API client know that certain fields are handled by a post
processor and also pass another parameter where it has to know that the set is
called xyz? Note that addressing the profile is not different from addressing
individual post processor names, it is an implementation detail.
It should behave like an extra sling post operation, which I believe would fail
if not present based on the _operation name_ aka _suffix name_ or prefix
"trick" as in my proposal above.
was (Author: alexander.klimetschek):
My view now is that a post processor that relies on the @Suffix mechanism where
the properties would be written differently, without failure, if the processor
is not active, is a problem of the processor. And slightly so for Sling
encouraging this fragile approach. The Sling Post servlet should have a
mechanism like I outlined above that gives a clear behavior, without a default
behavior fallback, without any implementation specific references the client
has to know about.
Why should an API client know that certain fields are handled by a post
processor and also pass another parameter where it has to know that the set is
called xyz? Note that addressing the profile is not different from addressing
individual post processor names, it is an implementation detail.
It should behave like an extra sling post operation, which I believe would fail
if not present, but as part of the normal sling post servlet mixed with normal
properties.
> 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-6187-profile.diff, SLING-6187-profile.diff,
> SLING-6187.patch
>
>
> 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)
[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15613238#comment-15613238
]
Alexander Klimetschek edited comment on SLING-6187 at 10/27/16 9:17 PM:
Could this check be based on the resource type? Then you'd configure the
required post processors based on the RT (or node type), and it's completely
server side.
This lets me think however, that whatever the @suffix triggers in the first
place (say an encryption of a property), which you want to guarantee, should
probably also be defined purely server side.
I.e. if the client forgets/omits the suffix, the requiredPostProcessor check
would not help and you still get an undesired result.
was (Author: alexander.klimetschek):
Could this check be based on the resource type? Then you'd configure the
required post processors based on the RT (or node type), and it's completely
server side.
This lets me think however, that whatever the @suffix triggers in the first
place (say an encryption of a property), which you want to guarantee, should
probably also be defined purely server side.
> 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
>
>
> 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)
[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606101#comment-15606101
]
Justin Edelson edited comment on SLING-6187 at 10/25/16 6:37 PM:
-
[~rr...@adobe.com] perhaps the description isn't clear -- the "list" is
populated as part of the request. The thesis being that only the party sending
the request knows what is necessary to handle it.
IIOW, this is about allowing the request to make assertions as to how it needs
to be handled (which is similar to the extant {{:operation}} parameter).
was (Author: justinedelson):
[~rr...@adobe.com] perhaps the description isn't clear -- the "list" is
populated as part of the request. The thesis being that only the party sending
the request knows what is necessary to handle it.
> 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
>
>
> 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)
[jira] [Comment Edited] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors
[
https://issues.apache.org/jira/browse/SLING-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606101#comment-15606101
]
Justin Edelson edited comment on SLING-6187 at 10/25/16 6:36 PM:
-
[~rr...@adobe.com] perhaps the description isn't clear -- the "list" is
populated as part of the request. The thesis being that only the party sending
the request knows what is necessary to handle it.
was (Author: justinedelson):
[~rr...@adobe.com] perhaps the description isn't clear -- the "list" is
populated as part of the request.
> 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
>
>
> 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)
