On 11/29/06, Bernhard Slominski <[EMAIL PROTECTED]> wrote:
Thanks for considering my issue. I think many are people are just not aware of this issue because they use another part of the Shale framwork and are not familiar with the details of the ClassRessourceProcssor, that why it should be explicitly enabled. As Hermond pointed out you should not have secure data unencyrtped in files but I saw many people do that. What we don't want is that some applications get in trouble and people say that Shale is a security risk to your application.
I've filed a JIRA issue[1] to track progress on this, and have some good news ... tonight's nightly build will include a capability to configure (via URL pattern matching) what resources a particular processor will deliver. In addition, the zero-config "out of the box" will allow resource access for the kinds of things you'd expect (*.js, *.css, and so on) but not sensitive things like *.properties files. Remaining tasks before we can call this issue fixed include: * Documenting how the new configuration scheme works, and what the defaults are (should get to this shortly) * Deciding what defaults to use for the "dynamic" processor that maps resource ids to a public method of a managed bean. Right now, no restrictions are enforced by default, because I couldn't think of any reasonable general policy (given that you can name a managed bean pretty much anything). This might even be a case where a conservative default (put "/*" on the excludes list) might make sense, and force the user to allow public access to only the beans they've designed for that purpose). I'm open to suggestions here. Bernhard Craig [1] https://issues.apache.org/struts/browse/SHALE-344
