On Tue, Nov 29, 2011 at 12:25 PM, Justin Edelson
<[email protected]> wrote:
>
> On Nov 29, 2011 11:34 AM, "Felix Meschberger" <[email protected]> wrote:
>>
>> Hi,
>>
>> Am 29.11.2011 um 17:30 schrieb Justin Edelson:
>>
>> > Hi,
>> >
>> > On Tue, Nov 29, 2011 at 11:00 AM, Felix Meschberger <[email protected]>
>> > wrote:
>> >> Hi,
>> >>
>> >> Another option would be to have a special ResourceProvider which
>> >> returns SyntheticResources in case of any access to below /bin which is 
>> >> not
>> >> backed by a registered servlet. Such a SyntheticResource would not allow 
>> >> the
>> >> POST Servlet to write anything back to anywhere !
>> >
>> > Doesn't this suffer from the same problem as described in the original
>> > JIRA description, i.e. if the component/bundle providing this
>> > ResourceProvider isn't started/active, then the POST would go through
>> > to the default POST Servlet.
>>
>> Basically, yes.
>>
>> >
>> > I'm thinking maybe the real problem isn't that the POST goes through
>> > to the default POST servlet but that the presence of a node at
>> > /bin/replicate prevents the servlet registered at that path from being
>> > executed.
>>
>> No, better matching resource providers overwrite more general ones. So if
>> there is a servlet at /bin/replicate, the node should actually be ignored.
>
> That was what I was trying to say :) If the original description is
> accurate, the more specific resource provider isn't getting picked up and
> that would be a bug.
>
> I can create an IT later in the week for this.

IT added in r1208215

Seems to be working.

>
> Justin
>
>
>>
>> Regards
>> Felix
>>
>> >
>> > WDYT?
>> >
>> > Justin
>> >
>> >>
>> >> Regards
>> >> Felix
>> >>
>> >> Am 29.11.2011 um 16:55 schrieb Carsten Ziegeler (Commented) (JIRA):
>> >>
>> >>>
>> >>>    [
>> >>> https://issues.apache.org/jira/browse/SLING-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159324#comment-13159324
>> >>> ]
>> >>>
>> >>> Carsten Ziegeler commented on SLING-2136:
>> >>> -----------------------------------------
>> >>>
>> >>> I think the right way is to use ACLs. Adding a new configuration
>> >>> option which basically is an ACL in a servlet is not the right approach.
>> >>>
>> >>> Another workaround is to add a servlet filter
>> >>>
>> >>>> Sling POST Servlet: Configuration of Allowed Paths
>> >>>> --------------------------------------------------
>> >>>>
>> >>>>                Key: SLING-2136
>> >>>>                URL: https://issues.apache.org/jira/browse/SLING-2136
>> >>>>            Project: Sling
>> >>>>         Issue Type: Improvement
>> >>>>         Components: Servlets
>> >>>>   Affects Versions: Servlets Post 2.1.2
>> >>>>           Reporter: Andrew Khoury
>> >>>>        Attachments: post_servlet_filter-1205238.patch
>> >>>>
>> >>>>
>> >>>> It would be nice if you could configure rules or regular expressions
>> >>>> for paths the sling post servlet is allowed to work under.  This would 
>> >>>> be
>> >>>> good for both security reasons and for protecting against conflicts with
>> >>>> other servlets.
>> >>>> For example:
>> >>>> Let's say you have a servlet ReplicationServlet registered to receive
>> >>>> POST requests under path /bin/replicate.
>> >>>> However, during startup, before the ReplicationServlet component has
>> >>>> been enabled, a user tries to do a POST to /bin/replicate.  In this 
>> >>>> case,
>> >>>> instead of executing the ReplicationServlet, the POST servlet is 
>> >>>> executed
>> >>>> and it creates a node under /bin/replicate.  Now, as long as the node
>> >>>> /bin/replicate exists... the ReplicationServlet will not be executed for
>> >>>> requests to /bin/replicate.  This presents a problem and explains the
>> >>>> necessity for this feature.
>> >>>
>> >>> --
>> >>> This message is automatically generated by JIRA.
>> >>> If you think it was sent incorrectly, please contact your JIRA
>> >>> administrators:
>> >>> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>> >>> For more information on JIRA, see:
>> >>> http://www.atlassian.com/software/jira
>> >>>
>> >>>
>> >>
>>

Reply via email to