Hi, Michael Marth schrieb: > 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.
It is difficult to decide, when json access is desired (for example if you have client-side JavaScript which wants to grab content) and when not (attack case) - I am not really sure, whether we can solve this with proper black/whitelisting. Maybe just some ACL should be enough. Regards Felix > > 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 >>> > > >
