So that marker should be and ACL containing an ACE with execute
privilege granted to the appropriate session.
I wasn't aware that there was such a privilege in the Jackrabbit
DefaultAccessManager or 283,
but I agree thats were it should be.
On a practical note,
Unless DefaultAccessManager et al is going to be re-implemented for
Sling, then this should go back to Jackrabbit as DAM is heavily
protected for obvious reasons, and when I looked trying to extend the
way in which principals for a session were resolved, there didn't
appear to be many (if any) extension points available in DAM since
registration of bits in the compiled privileges bitmap
(o
.a.j.core.security.authorization.PrivilegeRegistry.registerPrivilege)
is private (very)
Ian
On 2 Jun 2009, at 11:59, David Nuescheler wrote:
hi guys,
i really think this should be dealt with, using proper repository
access control.
as soon as we start to let the application deal with security we
need to
worry about it every specific application, and become prone to "xyz-
injection"
similar to the problem that db's have with "sql injection".
it becomes particularly tricky if you try to filter things out of the
query results
and the likes...
my personal guidance would be to make the access control "tighter"
in the
sense that one would forbid read privileges to "/apps" and "/homes"
for the
anonymous user (in case that is not desired) and have the script
execution
use a session with appropriate privileges to read and execute.
regards,
david
On Tue, Jun 2, 2009 at 12:50 PM, Ian Boston <i...@tfd.co.uk> wrote:
Felix,
+1
In addition, I would like to see a marker on the parent nodes that
designates the subtree as containing executable content.
Then the special session can be used to execute the scripts, but
only after
it had checked to see the script is located in an "executable"
subtree.
A suitably authorized user could read and write,
Perhaps this already exists ?
Ian
On 2 Jun 2009, at 11:33, Felix Meschberger wrote:
Hi,
John Crawford schrieb:
I have been working with sling for quite some time and, of
course, Day
products. One thing that I have been increasingly concerned with
is the
end
users ability to scrape all of the sites content and code with
minimal
effort using the built in functionality of the SlingPostServlet.
The Sling Get Servlet to be precise ;-)
For Example:
http://dev.day.com/discussion-groups/users.infinity.json
http://dev.day.com/discussion-groups/apps.infinity.json
As Jukka said, you may employ access control to prevent this.
But there is a glitch for the scripts located in /apps and /libs:
Currently scripts are read from the repository using the session
of the
current user, that is the request user.
So preventing access to
http://dev.day.com/discussion-groups/apps/mailingLists/mailingLists.jsp
by simply denying read-access for the anonymous user actually
prevents
using the site at all.
One solution to this problem could be to not load the scripts with
the
session of the current user but to use a special-purpose session
(for
example an admin session) to do this.
This way, you may lock down /apps and /libs for general
consumption but
may still execute the scripts in there.
WDYT ?
Regards
Felix
(this
one really disturbs me)
So far, my solution has been to provide a proxy (namely Apache2)
in front
of
sling to filter out any undesired requests. Seems to work. But,
by
doing
this, it takes way what is so cool about Sling. I have reported
to Day
Support numerous times, but they don't seem too concerned about
it. But
for
sites where the content is critical or where we require users to
pay for
our
content, it is very important to us.
Is there a better way to handle this?
Please let me know your thoughts.
Respectfully,
John
--
David Nuescheler
Chief Technology Officer
mailto: david.nuesche...@day.com
web: http://www.day.com/ http://dev.day.com
twitter: @daysoftware
