Hi,

thanks John, for pointing this out.

Part of the problem you describe is misconfigurations on my part (I did not
realize that the "anonymous" user is not part of the "everyone" group). But
as Felix has described the problem with the /apps directory cannot be fixed
by configuration. I just filed bug 989 [1] for this (an in-the-air collision
with Felix' mail).

As a third aspect: I believe there are parts in most sites where the json
representation is not desired. What do you think about making the json
servlet more configurable in terms of black/whitelisting properties it
renders? That would be on top of all other "proper" security measures, of
course.

Michael

[1] https://issues.apache.org/jira/browse/SLING-989

On Tue, Jun 2, 2009 at 12:33 PM, Felix Meschberger <fmesc...@gmail.com>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
> >
>



-- 
Michael Marth | http://dev.day.com/

Reply via email to