[
https://issues.apache.org/jira/browse/SLING-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190218#comment-13190218
]
Justin Edelson commented on SLING-2236:
---------------------------------------
The problem is that JCR (and the JCR Resource Resolver) doesn't differentiate
between "nodes that you can't see" and "nodes that don't exist". So this would
require opening up an admin session.
As a workaround, you could create a SlingPostOperation which handles
:operation=foo and return the error you want in that particular case.
> 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
>
> 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
