Hi,
first of all thanks for your feedback! I appreciate every information
available.
Please see my comments inline.
Am 06.04.12 03:37, schrieb maikhorma:
I'm not an expert but since you didn't get a reply, let me offer what I
can... First of all, your curl statement might not actually do what you
expect. You are removing the acl entry for the everyone group but that does
not necessarily mean you removed the acl for the anonymous user. (I was
Yes, maybe the anonymous user is just a special user that is not within
the everyone group.
unable to recreate your issue following what you gave)
I can reproduce that at the latest trunk without the /sling context and
at Sling 6 with the downloadable war file deployed at /sling. Did you
consider the context when applying the curl command?
2nd, there are configuration options in the Sling Authentication bundle
where you can disable the anonymous account and specify locations that don't
need authentication that may help you get what your trying to do. Sorry I
don't have it in front of me but if you need I can follow up with more
specifics on where that is.
No problem, I already considered that. One can see these locations
relative to the sling context here: /system/console/slingauth
After executing the curl command the browser redirects to
system/sling/selector/login which redirects back to
system/sling/selector/login when the user is not logged in. But looking
at the management console page you refered to
(/system/console/slingauth) this exact path is specified as not
requiring authentication. The SelectorFormServlet from the
org.apache.sling.auth.selector specifies that. Probably for avoiding
this redirect loop.
3rd. Be careful with denying access to everyone at the root. I found that
after configuring the security that I thought was ideal, i wasn't able to
create versionable objects, because the user didn't have read access to
/jcr:system/jcr:versionStorage. I ended up having to relax the permissions
at the root level then deny them where i needed strict security.
Thanks for the hint. This is good to know.
Maybe it's best practice in Sling and/or Jackrabbit to allow anonymous
to read the root node. I don't know. But it seems not preferable to me
because one would need to make sure to set the permissions for every new
child node he should not see. But maybe I miss something.
Best,
Sandro
Sandro Boehme wrote
Hi,
I would like to remove the default read permission of the everyone
principle from the root node
(curl -F:applyTo=everyone
http://admin:admin@localhost:8080/sling/.deleteAce.html) to only set it
on sub nodes when needed and to avoid that every new sub node is
readable by everyone by default.
If I remove that permission and navigate to http://localhost:8080/sling/
the Selector Form Handler
creates infinite redirects to
http://localhost:8080/system/sling/selector/login?j_reason=User+name+and+password+do+not+match&resource=%2F
leading to a 310 too_many_redirects error.
I guess this happens because this selector expects
/system/sling/selector/login to require authentication.
But as seen in the authenticator web console page
(http://localhost:8080/system/console/slingauth) the same
selector sets authentication required to "no" for the
/system/sling/selector/login path.
Is it possible to get that to work?
Best,
Sandro
--
View this message in context:
http://apache-sling.73963.n3.nabble.com/remove-the-read-permission-of-anonymous-from-the-root-node-tp3866195p3889171.html
Sent from the Sling - Users mailing list archive at Nabble.com.
