[
https://issues.apache.org/jira/browse/SLING-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190990#comment-13190990
]
Felix Meschberger commented on SLING-2236:
------------------------------------------
The developer is doing the wrong thing by re-using API (:operation parameter)
of the Sling POST Servlet and then seeing unexpected behavior.
We should not change this in the Sling POST Servlet because conceptually it
makes no sense. At the end of the day, everything is there in the log message:
Indication of the Sling POST Servlet instead of the expected servlet handling
the request and the wrong operation used. Looking at the RequestProgressLog you
might even see a hint that the unexpected servlet has been called.
> Default POST servlet reports invalid operation when it should report 404
> ------------------------------------------------------------------------
>
> Key: SLING-2236
> URL: https://issues.apache.org/jira/browse/SLING-2236
> Project: Sling
> Issue Type: Bug
> Components: Servlets
> Reporter: Jeff Young
> Priority: Minor
>
> In sling/servlets/post/impl/SlingPostServlet.java's doPost() method, we look
> up the operation (and report an unknown operation) before checking
> privileges. I'd
> like to propose that when the operation is not understood, we first check for
> read access to the resource, and if unsuccessful, report that instead of
> reporting
> "invalid operation".
> Here's the issue: say I define my own POST servlet which supports
> :operation="foo". I set a sling:resourceType so that my POST servlet gets
> invoked. All fine
> and good.
> Now someone without read access to the resource tries to do an
> :operation="foo". Sling can't read the sling:resourceType (no read access),
> and so invokes the
> default POST servlet instead of my custom POST servlet. It looks up
> :operation="foo" and reports "invalid operation" (which is pretty misleading).
--
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
