Michael, No worries at all. I figured I could resolve most of this through a front end proxy (like Apache2), but wanted to see if there was a better way.
+1 on the json restriction. Would be kind of cool to be able to restrict/grant access based upon a regexp as well. Thank you for your help. Respectfully, John On Tue, Jun 2, 2009 at 6:03 AM, Michael Marth <mma...@day.com> wrote: > 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/ >
