Craig, thanks for the quick fix! I think of the defaults for the dynamic processor and leave it as comment in JIRA.
Bernhard > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag > von Craig > McClanahan > Gesendet: Freitag, 1. Dezember 2006 00:08 > An: dev@shale.apache.org > Betreff: Re: Security in Remoting: ClassResourceProcessor > > > 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 >
