[
https://issues.apache.org/jira/browse/SLING-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483308#comment-13483308
]
Carsten Ziegeler commented on SLING-1176:
-----------------------------------------
Isn't this an incompatible change as it is implemented in the patch? Right now
ResourceResolver#getResource would return null if the user has no access to an
item whereas with the patch an exception would be thrown. Maybe the change is
correct according to the javadocs but still a change in behaviour and
potentially breaking existing applications.
So the exception should only be thrown for ResourceResolver#resolve
> Reimplement support for access failure notification in the ResourceResolver
> ---------------------------------------------------------------------------
>
> Key: SLING-1176
> URL: https://issues.apache.org/jira/browse/SLING-1176
> Project: Sling
> Issue Type: New Feature
> Components: API, Engine, JCR
> Affects Versions: JCR Resource 2.0.6, Engine 2.0.6, API 2.0.8
> Reporter: Felix Meschberger
> Attachments: api_access_denied.patch, engine_access_denied.patch,
> jcr_resource_access_denied.patch
>
>
> As of SLING-319 (SVN Rev. 636296) functionality was removed from the
> ResourceResolver implementation to signal that a resource exists but is not
> accessible. The goal was to align the behaviour of the resource resolver to
> the behaviour of JCR which does not distinguish between non-existing and
> non-accessible resource.
> The consequence of this change is that the application cannot properly
> distinguish between the two states and has to resort to guessing about the
> situation and also guess as to whether different authentication should be
> requested or not.
> Over time it became evident, that this behaviour makes the application too
> complex. Unfortunately, we cannot "fix" JCR to distinguish between
> non-existing and non-accessible. So we have to reinsert the checks removed in
> Rev. 636296 to be able to distinguish.
> The exception conveyed will be defined in the Sling API and extend from
> SlingException, thus being a RuntimeException. The SlingMainServlet will
> catch this exception (as it catches the NonExistingResource exception) and
> calls HttpServletResponse.sendError(403) (FORBIDDEN). An error handler script
> for 403/FORBIDDEN can then decide on whether to request authentication or
> send 403 or hide the fact that a resource would exist and in fact send a
> 404/NOT FOUND code.
> The change of the ResourceResolver is compatible with previous versions
> because the new exception thrown extends SlingException and the methods are
> already documented to potentially throw SlingException. In this respect it is
> just a refinement.
> Changes required:
> * Add new exception conveying denied access situation providing the path to
> the resource to which access was denied
> * Add JavaDoc to ResourceResolver API to document potential new access
> denial exception
> * Add support to SlingMainServlet to convert the exception into a
> 403/FORBIDDEN status
> * Reimplement the functionlity removed in Rev. 636296
> The version of the o.a.s.resource package will be raised to 2.1 since this
> change requires adaptions in the implementation. The bundle version of the
> jcr/resource bundle might also be increased to the next minor version to
> indicate this new functionality.
> NOTE: Downstream applications currently handling 404/NOT FOUND to try to
> distinguish between non-existing and non-accessible must be adapted.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
