[jira] Issue Comment Edited: (JCR-2867) Read-only session

["angela (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCR-2867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984739#action_12984739 ] 

angela edited comment on JCR-2867 at 1/21/11 9:07 AM:
------------------------------------------------------

> My idea here is that you could use this mechanism to enforce high-level constraints like "no writes on GET"...

and my idea was when we discussed that half a year ago that having such a session would allow to
prevent unintended write operations in cases where they should never occur by design... currently there is
just now way to prevent that, exception from being careful and keeping an eye on the code.

      was (Author: anchela):
    > My idea here is that you could use this mechanism to enforce high-level constraints like "no writes on GET"...

and my idea was when we discussed that half a year ago that having such a session would allow to
prevent unintended write operations in cases where they should occur by design... currently there is
just now way to prevent that, exception from being careful and keeping an eye on the code.
  
> Read-only session
> -----------------
>
>                 Key: JCR-2867
>                 URL: https://issues.apache.org/jira/browse/JCR-2867
>             Project: Jackrabbit Content Repository
>          Issue Type: New Feature
>          Components: jackrabbit-core
>            Reporter: Jukka Zitting
>
> It would be nice to have a way to declare that a given JCR session will only be used for reading, regardless of the access rights of the logged in user. This would be useful for example in web applications that want to enforce constraints like allowing no writes during processing of GET requests.
> This could be implemented for example as a per-session flag that could be set through an extra parameter in the login() call, like this: repository.login("workspace-name?readonly", credentials);
> Alternatively a security manager could be connected with a ThreadLocal variable set for example by a servlet filter based on the current request method.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.