[jira] Created: (SLING-1176) Reimplement support for access failure notification in the ResourceResolver

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (SLING-1176) Reimplement support for access failure notification in the ResourceResolver

Oliver Lietz (Jira)
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, JCR
    Affects Versions: API 2.0.8, JCR Resource 2.0.6
            Reporter: Felix Meschberger
             Fix For: JCR Resource 2.0.8


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.
-
You can reply to this email to add a comment to the issue online.


Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (SLING-1176) Reimplement support for access failure notification in the ResourceResolver

Oliver Lietz (Jira)

     [ https://issues.apache.org/jira/browse/SLING-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger updated SLING-1176:
-------------------------------------

    Attachment: engine_access_denied.patch
                jcr_resource_access_denied.patch
                api_access_denied.patch

Proposed patches:

  * Add new exception to API and document its use in the ResourceResolver interface
  * Add support for throwing this exception in the JCR based resource resolver
  * Handle exception sending a 403/FORBIDDEN in the SlingMainServlet

> 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, JCR
>    Affects Versions: JCR Resource 2.0.6, API 2.0.8
>            Reporter: Felix Meschberger
>             Fix For: JCR Resource 2.0.8
>
>         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.
-
You can reply to this email to add a comment to the issue online.


Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SLING-1176) Reimplement support for access failure notification in the ResourceResolver

Oliver Lietz (Jira)
In reply to this post by Oliver Lietz (Jira)

    [ https://issues.apache.org/jira/browse/SLING-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774959#action_12774959 ]

Ian Boston commented on SLING-1176:
-----------------------------------

Some Comments.

1.

In the getAdminSession(String workspaceName) method, it might be better to use a ConcurrentHashMap and reduce the scope of the synchronized block so it isnt active on every request.
eg
check the session from the map is a) not null and b) active.
If so return session
else {
 syncronise() {
   check the session from the map is a) not null and b) active.
   If so return
   else {
    create a new session and add to the map
   }
 }
}



2.
The exports in bundle/api/pom.xml look like they might become problematic from a support point of view, although we probably cant avoid this.



> 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, JCR
>    Affects Versions: JCR Resource 2.0.6, API 2.0.8
>            Reporter: Felix Meschberger
>             Fix For: JCR Resource 2.0.8
>
>         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.
-
You can reply to this email to add a comment to the issue online.


Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SLING-1176) Reimplement support for access failure notification in the ResourceResolver

Oliver Lietz (Jira)
In reply to this post by Oliver Lietz (Jira)

    [ https://issues.apache.org/jira/browse/SLING-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774969#action_12774969 ]

Felix Meschberger commented on SLING-1176:
------------------------------------------

@1: good point, will consider
@2: what kind of problems ?

> 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, JCR
>    Affects Versions: JCR Resource 2.0.6, API 2.0.8
>            Reporter: Felix Meschberger
>             Fix For: JCR Resource 2.0.8
>
>         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.
-
You can reply to this email to add a comment to the issue online.


Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SLING-1176) Reimplement support for access failure notification in the ResourceResolver

Oliver Lietz (Jira)
In reply to this post by Oliver Lietz (Jira)

    [ https://issues.apache.org/jira/browse/SLING-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774995#action_12774995 ]

Ian Boston commented on SLING-1176:
-----------------------------------

@2,
manual maintenance of the version numbers. (not  a big problem bit needs to be done)

> 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, JCR
>    Affects Versions: JCR Resource 2.0.6, API 2.0.8
>            Reporter: Felix Meschberger
>             Fix For: JCR Resource 2.0.8
>
>         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.
-
You can reply to this email to add a comment to the issue online.


Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SLING-1176) Reimplement support for access failure notification in the ResourceResolver

Oliver Lietz (Jira)
In reply to this post by Oliver Lietz (Jira)

    [ https://issues.apache.org/jira/browse/SLING-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774999#action_12774999 ]

Felix Meschberger commented on SLING-1176:
------------------------------------------

Thanks for the clarification. I will take that to the list, since I think it is important to have it discussed in the general context of versioning. Thanks for noting.

> 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, JCR
>    Affects Versions: JCR Resource 2.0.6, API 2.0.8
>            Reporter: Felix Meschberger
>             Fix For: JCR Resource 2.0.8
>
>         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.
-
You can reply to this email to add a comment to the issue online.


Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (SLING-1176) Reimplement support for access failure notification in the ResourceResolver

Oliver Lietz (Jira)
In reply to this post by Oliver Lietz (Jira)

     [ https://issues.apache.org/jira/browse/SLING-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger updated SLING-1176:
-------------------------------------

          Component/s: Engine
    Affects Version/s: Engine 2.0.6
        Fix Version/s: API 2.0.10
                       Engine 2.1.0

> 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
>             Fix For: JCR Resource 2.0.8, Engine 2.1.0, API 2.0.10
>
>         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.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (SLING-1176) Reimplement support for access failure notification in the ResourceResolver

Oliver Lietz (Jira)
In reply to this post by Oliver Lietz (Jira)

     [ https://issues.apache.org/jira/browse/SLING-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger updated SLING-1176:
-------------------------------------

    Fix Version/s:     (was: Engine 2.1.0)
                       (was: JCR Resource 2.0.8)
                       (was: API 2.0.10)

Descheduling this issue because we will not implement this yet...

> 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.
-
You can reply to this email to add a comment to the issue online.