On 15 Sep 2010, at 05:01, Justin Edelson wrote:
FYI - Created JCR-2748 and submitted a patch to provide a simple way to
disable anonymous access to the security workspace.
Ian - have you looked at turning the Sakai server bundle into a fragment
attached to the Sling JCR Jackrabbit Server
On 9/15/10 4:36 PM, Ian Boston wrote:
On 15 Sep 2010, at 05:01, Justin Edelson wrote:
FYI - Created JCR-2748 and submitted a patch to provide a simple way to
disable anonymous access to the security workspace.
Ian - have you looked at turning the Sakai server bundle into a fragment
FYI - Created JCR-2748 and submitted a patch to provide a simple way to
disable anonymous access to the security workspace.
Ian - have you looked at turning the Sakai server bundle into a fragment
attached to the Sling JCR Jackrabbit Server bundle? I do that with a
custom FileSystem and
Oh... I get it. There's no ACL on the user and group nodes in the
security workspace.
But trying to apply an ACL to / or /rep:security returns an exception
$ curl-FprincipalId=anonymous -fprivil...@jcr:all=denied
IIRC the security workspace is not set up with access controllable nodes, so
you cant use a policy on a node.
We did [1] for the securty workspace.
1
On 12 Sep 2010, at 00:25, Felix Meschberger wrote:
There is one situation where an admin session is always retrieved: The
CreeateUser servlet. This is probably a bug and should only use an admin
session for self-registration.
+1,
I think we have modified out CreateUser servlet to do this,
I can create patches then to prevent anon access. What do you think about tying
the authorization to existing JCR ACL's like jcr:readAccessControl or
jcr:modifyAccessControl? If there is interest, I can include this in my patches.
-- Mike
On Sep 9, 2010, at 5:07 PM, Justin Edelson wrote:
I
