http://jumpstart.doublenegative.com.au:8080/jumpstart/assets/ctx/9f6f05886c53821a/WEB-INF/classes/jumpstart/web/services/AppModule.class
you can access the entire web app, it even gives you directory listings Geoff Callender-2 wrote: > > Isn't this simply due to a Maven convention which has passed its "use > by" date? Why not put .java, .tml, and .properties together in the > source tree, and compile them all into WEB-INF/classes/ where they're > automatically hidden from the users? Surely this makes so much sense. > It's what I do with Ant and it seems to work a treat. Or have I missed > something? > > Eg. correct me if I'm wrong but I'm pretty sure that only the css and > images are downloadable from here: > http://jumpstart.doublenegative.com.au:8080/jumpstart/ > > Geoff > > On 14/08/2009, at 7:07 PM, Juan E. Maya wrote: > >> The ResourceDigestGenerator by default secures files with extension: >> .tml and .class. To add more restrictions you'd have to contribute >> ResourceDigestGenerator. Something like this: >> >> public static void >> contributeResourceDigestGenerator(Configuration<String> configuration) >> { >> configuration.add("properties"); >> configuration.add("xml"); >> } >> >> However i agree that this should be documented or even created by the >> maven archetype. It's something a new user could easily forget with >> devastating consequences. >> >> On Fri, Aug 14, 2009 at 4:29 AM, kartweel<r...@exemail.com.au> wrote: >>> >>> Hi Guys, Sorry to pull up an old thread, but there doesn't seem to >>> be a lot >>> about this topic. Was there ever a nice solution implemented for >>> this? 2 >>> years of tapestry framework development later and I can still >>> download all >>> my class files. I've restricted assets to "authenticated users" >>> using a >>> method like below, but I thought by now we wouldn't need to be >>> adding custom >>> solutions to manage this and it would be part of the core project?? >>> >>> >>> Robert Zeigler wrote: >>>> >>>> I don't plan on changing the default configuration from whitelist to >>>> blacklist... it's the fallback. >>>> I'm a fan of "deny unless explicitly authorized", as well. The >>>> AssetProtectionDispatcher >>>> takes an ordered configuration of AssetPathAuthorizer's, with the >>>> default whitelist implementation >>>> being the "catch all" final authorizer in what amounts to a chain of >>>> command. So you can certainly >>>> contribute your own implementations of authorizer on top of the >>>> default. Having a pattern matching >>>> whitelist would certainly be useful; I'm in a time crunch at the >>>> moment (and basically will be until the end of August), >>>> but in the beginning of September, I will rework the default >>>> WhitelistAuthorizer to accept url patterns. >>>> >>>> Robert >>>> >>>> On Aug 3, 2007, at 8/38:27 AM , Thiago H de Paula Figueiredo wrote: >>>> >>>>> On Fri, 03 Aug 2007 10:03:37 -0300, Francois Armand >>>>> <farm...@linagora.com> wrote: >>>>> >>>>>> Thiago H de Paula Figueiredo wrote: >>>>>>> Would a black list intead of a white list better? I suppose there >>>>>>> are less files to hide than files to allow access. >>>>>> Well, I think that one of the best principle in security is >>>>>> "explicit authorization" : you just do not want that a >>>>>> confidential file is accessible by error, because a user forgot to >>>>>> hide it. >>>>> >>>>> That's a very good point. ;) >>>>> >>>>>> But I agree that the white list should authorize jokers to enable >>>>>> "*.jpg" kind of filter (and if you name your confidential file >>>>>> "picture_of_my_secret_weapon.jpg", well, to bad for you ;) >>>>> >>>>> Maybe we could allow any .jpg, .gif, .jpg and .css file by default >>>>> and explicitly whitelist the rest. >>>>> And no, I don't want to see the picture of your secret weapon, >>>>> whatever it is. :P >>>>> >>>>> Thiago >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/-T5--Security-of-files-in-the-classpath-tp11816097p24965558.html >>> Sent from the Tapestry - User mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > > -- View this message in context: http://www.nabble.com/-T5--Security-of-files-in-the-classpath-tp11816097p24980563.html Sent from the Tapestry - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
