You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Thiago H de Paula Figueiredo <th...@gmail.com> on 2007/07/26 20:09:08 UTC
[T5] Security of files in the classpath
Hi!
I'm developing a Tapestry 5 application and I was looking at access to
assets via URLs. I typed http://localhost:8080/assets/tapestry/default.css
to take a look at T5 default CSS values.
Then I typed http://localhost:8080/assets/hibernate.cfg.xml . . . and it
showed that file. It's a security flaw.
Is there any measure already implemented against this kind of attack? It
would be very nice if we could block asset access to files and folders
through some Tapestry-IoC contribution. ;)
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 26 Jul 2007 18:18:42 -0300, Chris Lewis
<ch...@bellsouth.net> wrote:
> I think hat's a legitimate problem. I know in T4 a checksum was
> generated by links to assets and then verified by tapestry before
> yielding the actual asset (by verifying the sum). However the fact that
> you can use the asset service to pull any arbitrary file out of the
> classpath, even those that are not declared as assets, seems like a
> serious issue. I also would like to know a solution (simply restricting
> the service to only declared assets should do, but how?).
I think there is a simple solution: create a configuration point
(contribution in Tapestry IoC) to the AssertService (I just guessed the
name) so you can tell it which files can't be accessed as an asset.
JIRA anyone?
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Chris Lewis <ch...@bellsouth.net>.
I think hat's a legitimate problem. I know in T4 a checksum was
generated by links to assets and then verified by tapestry before
yielding the actual asset (by verifying the sum). However the fact that
you can use the asset service to pull any arbitrary file out of the
classpath, even those that are not declared as assets, seems like a
serious issue. I also would like to know a solution (simply restricting
the service to only declared assets should do, but how?).
chris
Thiago H de Paula Figueiredo wrote:
> On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue <te...@gmail.com>
> wrote:
>
>> Hi, Just don't put configuration resources there.
>
> I'm not sure you had understood what I've said.
>
> My hibernate.cfg.xml is in /src/main/resources. So it is copied by
> Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And anything
> in the classpath, as far as I can see, is accessible via
> <applicatiourl>/assets. As many frameworks expect their configuration
> files to be in the classpath, I think we have a little, easy to solve
> problem here. :)
>
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Daniel Jue <te...@gmail.com>.
> I have just tried to post but Apache's JIRA threw a NullPointerException .
> . .
That made me laugh.
It seems previous versions had problems with information hiding as well:
https://issues.apache.org/jira/browse/TAPESTRY-281
https://issues.apache.org/jira/browse/TAPESTRY-1175
Reminds me of the old IIS days...classic pentesting fodder.
On 7/27/07, Thiago H de Paula Figueiredo <th...@gmail.com> wrote:
> On Fri, 27 Jul 2007 09:59:16 -0300, Robin Helgelin <lo...@gmail.com>
> wrote:
>
> > If someone adds a JIRA issue I'm pretty sure Howard is able to solve
> > this in the best interests of T5.
>
> I have just tried to post but Apache's JIRA threw a NullPointerException .
> . .
>
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 27 Jul 2007 09:59:16 -0300, Robin Helgelin <lo...@gmail.com>
wrote:
> If someone adds a JIRA issue I'm pretty sure Howard is able to solve
> this in the best interests of T5.
I have just tried to post but Apache's JIRA threw a NullPointerException .
. .
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Robin Helgelin <lo...@gmail.com>.
On 7/27/07, Chris Lewis <ch...@bellsouth.net> wrote:
> I'm quite new to Tapestry and just 2 days ago have started working with
> Tap 5. I realize the two (4 vs 5) are disparately different, but one of
> the things nice about the Tap 4 asset service was the checksum feature I
> mentioned that would deny access unless the sum in the url matched that
> of the file. My newness to Tap may show here, but why can't the asset
> service simply ignore requests for files that are not marked (@Asset) as
> assets? I mean doesn't a deny-all first and allow explicit exceptions
> strategy seem much more sane then providing an open door to the whole
> classpath (class bytes included??)?
If someone adds a JIRA issue I'm pretty sure Howard is able to solve
this in the best interests of T5.
--
regards,
Robin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Markus Joschko <ma...@gmail.com>.
Thanks. In the meantime I found an old posting which basically
contains the same solution.
I'll add it immediately. However I think that should be adressed by
tapestry in a hotfix released,
as every web developer assumes that the files in WEB-INF are save.
On Sat, Aug 15, 2009 at 1:34 PM, martijn.list<ma...@gmail.com> wrote:
> A follow up:
>
> I forgot to add gif
>
> private static final String[] ASSET_WHITE_LIST = {"jpg", "jpeg", "png",
> "gif", "js", "css", "ico"};
>
> /*
> * All the assets that are allowed to be downloaded using the assets service
> (including files without extension and dirs)
> */
> private static final Set<String> assetsWhitelist =
> Collections.synchronizedSet(
> new HashSet<String>(Arrays.asList(ASSET_WHITE_LIST)));
>
>
> martijn.list wrote:
>>
>> Markus Joschko wrote:
>>>
>>> So the ResourceDigestGenerator obiously doesn't protect the class or
>>> tml files for me here.
>>> I am currently thinking of taking the webapplication down as there is
>>> no way of securing passwords in this set4ting.
>>>
>>> Is there a workaround?
>>>
>>
>> I use a HttpServletRequestFilter to whitelist certain assets. I'm still on
>> 5.0.18 so I do not know whether it works with 5.1:
>>
>> /*
>> * All the assets that are allowed to be downloaded using the assets
>> service (including files without extension and dirs)
>> */
>> private static final HashSet<String> assetsWhitelist = new
>> HashSet<String>(Arrays.asList("jpg", "jpeg", "png", "js", "css", "ico"));
>>
>> public void
>> contributeHttpServletRequestHandler(OrderedConfiguration<HttpServletRequestFilter>
>> configuration,
>> @Inject @Value("${access-denied-page}") final String
>> accessDeniedPage)
>> {
>> /*
>> * Create a filter that will block access to some assets. The asset
>> service allows access to some assets we do
>> * not want to expose. The asset service will show all files in
>> /assets/ directory and allows you (by default)
>> * to download some files which you do not want to expose.
>> */
>> HttpServletRequestFilter filter = new HttpServletRequestFilter()
>> {
>> public boolean service(HttpServletRequest request,
>> HttpServletResponse response, HttpServletRequestHandler handler)
>> throws IOException
>> {
>> String path = request.getServletPath();
>>
>> if (path.startsWith("/assets") && (!assetsWhitelist.contains(
>>
>> StringUtils.lowerCase(FilenameUtils.getExtension(path)))))
>> {
>> response.sendRedirect(request.getContextPath() + "/" +
>> accessDeniedPage);
>>
>> return true;
>> }
>>
>> return handler.service(request, response);
>> }
>> };
>>
>> configuration.add("AssetProtectionFilter", filter , "before:*");
>> }
>>
>> Kind regards,
>>
>> Martijn Brinkers
>>
>
>
> --
> Djigzo open source email encryption
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by "martijn.list" <ma...@gmail.com>.
A follow up:
I forgot to add gif
private static final String[] ASSET_WHITE_LIST = {"jpg", "jpeg", "png",
"gif", "js", "css", "ico"};
/*
* All the assets that are allowed to be downloaded using the assets
service (including files without extension and dirs)
*/
private static final Set<String> assetsWhitelist =
Collections.synchronizedSet(
new HashSet<String>(Arrays.asList(ASSET_WHITE_LIST)));
martijn.list wrote:
> Markus Joschko wrote:
>> So the ResourceDigestGenerator obiously doesn't protect the class or
>> tml files for me here.
>> I am currently thinking of taking the webapplication down as there is
>> no way of securing passwords in this set4ting.
>>
>> Is there a workaround?
>>
>
> I use a HttpServletRequestFilter to whitelist certain assets. I'm still
> on 5.0.18 so I do not know whether it works with 5.1:
>
> /*
> * All the assets that are allowed to be downloaded using the assets
> service (including files without extension and dirs)
> */
> private static final HashSet<String> assetsWhitelist = new
> HashSet<String>(Arrays.asList("jpg", "jpeg", "png", "js", "css", "ico"));
>
> public void
> contributeHttpServletRequestHandler(OrderedConfiguration<HttpServletRequestFilter>
> configuration,
> @Inject @Value("${access-denied-page}") final String
> accessDeniedPage)
> {
> /*
> * Create a filter that will block access to some assets. The asset
> service allows access to some assets we do
> * not want to expose. The asset service will show all files in
> /assets/ directory and allows you (by default)
> * to download some files which you do not want to expose.
> */
> HttpServletRequestFilter filter = new HttpServletRequestFilter()
> {
> public boolean service(HttpServletRequest request,
> HttpServletResponse response, HttpServletRequestHandler handler)
> throws IOException
> {
> String path = request.getServletPath();
>
> if (path.startsWith("/assets") && (!assetsWhitelist.contains(
>
> StringUtils.lowerCase(FilenameUtils.getExtension(path)))))
> {
> response.sendRedirect(request.getContextPath() + "/" +
> accessDeniedPage);
>
> return true;
> }
>
> return handler.service(request, response);
> }
> };
>
> configuration.add("AssetProtectionFilter", filter , "before:*");
> }
>
> Kind regards,
>
> Martijn Brinkers
>
--
Djigzo open source email encryption
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by "martijn.list" <ma...@gmail.com>.
Markus Joschko wrote:
> So the ResourceDigestGenerator obiously doesn't protect the class or
> tml files for me here.
> I am currently thinking of taking the webapplication down as there is
> no way of securing passwords in this setting.
>
> Is there a workaround?
>
I use a HttpServletRequestFilter to whitelist certain assets. I'm still
on 5.0.18 so I do not know whether it works with 5.1:
/*
* All the assets that are allowed to be downloaded using the assets
service (including files without extension and dirs)
*/
private static final HashSet<String> assetsWhitelist = new
HashSet<String>(Arrays.asList("jpg", "jpeg", "png", "js", "css", "ico"));
public void
contributeHttpServletRequestHandler(OrderedConfiguration<HttpServletRequestFilter>
configuration,
@Inject @Value("${access-denied-page}") final String
accessDeniedPage)
{
/*
* Create a filter that will block access to some assets. The asset
service allows access to some assets we do
* not want to expose. The asset service will show all files in
/assets/ directory and allows you (by default)
* to download some files which you do not want to expose.
*/
HttpServletRequestFilter filter = new HttpServletRequestFilter()
{
public boolean service(HttpServletRequest request,
HttpServletResponse response, HttpServletRequestHandler handler)
throws IOException
{
String path = request.getServletPath();
if (path.startsWith("/assets") && (!assetsWhitelist.contains(
StringUtils.lowerCase(FilenameUtils.getExtension(path)))))
{
response.sendRedirect(request.getContextPath() + "/" +
accessDeniedPage);
return true;
}
return handler.service(request, response);
}
};
configuration.add("AssetProtectionFilter", filter , "before:*");
}
Kind regards,
Martijn Brinkers
--
Djigzo open source email encryption
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Markus Joschko <ma...@gmail.com>.
Ouch. This is a CRITICAL issue. I have a "normal" tapestry application
(5.1.0.5) without additional security checks and
I can download anything from my Web-Inf directory. Property files,
class files, everything. Also the tml files are accessible from the
outside world.
So the ResourceDigestGenerator obiously doesn't protect the class or
tml files for me here.
I am currently thinking of taking the webapplication down as there is
no way of securing passwords in this setting.
Is there a workaround?
Regards,
Markus
On Sat, Aug 15, 2009 at 5:54 AM, kartweel<rh...@exemail.com.au> wrote:
>
> I thought the digest generator is meant to make a different digest for each
> file, but it seems to be for the whole app?, or is that nnnnnnnn bit
> something to do with app versioning for caching and what not and not the
> digest?. This whole thread has some ideas for a white list approach to files
> on the classpath, but I thought by now tapestry would have something out of
> the box rather than a custom solution for it... I'm having a look into the
> resourceDigestGenerator, but at the moment it isn't the highest thing on my
> list.
>
>
> Geoff Callender-2 wrote:
>>
>> Ouch, now I get it. WEB-INF and all its contents are in fact visible,
>> directly below yourapp/assets/ctx/nnnnnnnnnnnnnnnn/, and it's not hard
>> to find out the value of nnnnnnnnnnnnnnnn.
>>
>> Suggestions anyone?
>>
>
> --
> View this message in context: http://www.nabble.com/-T5--Security-of-files-in-the-classpath-tp11816097p24981387.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by "Juan E. Maya" <ma...@gmail.com>.
I've Voted too. Also thanks to "kartweel" for pointing this out. It
seems the is not ResourceDigestGenerator applied to asset resources
:S It's a nasty bug :(
On Sat, Aug 15, 2009 at 2:41 PM, Geoff
Callender<ge...@gmail.com> wrote:
> Thanks, Thiago. I've voted for it. To everyone who is concerned about this,
> please vote too.
>
> On 15/08/2009, at 10:22 PM, Thiago H. de Paula Figueiredo wrote:
>
>> Em Sat, 15 Aug 2009 00:37:45 -0300, Geoff Callender
>> <ge...@gmail.com> escreveu:
>>
>>> Ouch, now I get it. WEB-INF and all its contents are in fact visible,
>>> directly below yourapp/assets/ctx/nnnnnnnnnnnnnnnn/, and it's not hard to
>>> find out the value of nnnnnnnnnnnnnnnn.
>>
>> I couldn't find any JIRA issue about it, so I created one:
>> https://issues.apache.org/jira/browse/TAP5-815.
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java consultant, developer, and instructor
>> http://www.arsmachina.com.br/thiago
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Fri, 14 Aug 2009 09:28:48 -0300, Geoff Callender
<ge...@gmail.com> escreveu:
> Isn't this simply due to a Maven convention which has passed its "use
> by" date?
I don't think so.
> 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?
Maven, when packaging a web app, copies all the files inside
src/main/resources to the classpath root folder (WEB-INF/classes in web
applications).
The issue here is about how Tapestry handles asset classpath requests.
> 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?
Yes. :) In this case, Ant and Maven are just different tools used to
package webapps.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Geoff Callender <ge...@gmail.com>.
Thanks, Thiago. I've voted for it. To everyone who is concerned about
this, please vote too.
On 15/08/2009, at 10:22 PM, Thiago H. de Paula Figueiredo wrote:
> Em Sat, 15 Aug 2009 00:37:45 -0300, Geoff Callender <geoff.callender.jumpstart@gmail.com
> > escreveu:
>
>> Ouch, now I get it. WEB-INF and all its contents are in fact
>> visible, directly below yourapp/assets/ctx/nnnnnnnnnnnnnnnn/, and
>> it's not hard to find out the value of nnnnnnnnnnnnnnnn.
>
> I couldn't find any JIRA issue about it, so I created one: https://issues.apache.org/jira/browse/TAP5-815
> .
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 15 Aug 2009 00:37:45 -0300, Geoff Callender
<ge...@gmail.com> escreveu:
> Ouch, now I get it. WEB-INF and all its contents are in fact visible,
> directly below yourapp/assets/ctx/nnnnnnnnnnnnnnnn/, and it's not hard
> to find out the value of nnnnnnnnnnnnnnnn.
I couldn't find any JIRA issue about it, so I created one:
https://issues.apache.org/jira/browse/TAP5-815.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by kartweel <rh...@exemail.com.au>.
I thought the digest generator is meant to make a different digest for each
file, but it seems to be for the whole app?, or is that nnnnnnnn bit
something to do with app versioning for caching and what not and not the
digest?. This whole thread has some ideas for a white list approach to files
on the classpath, but I thought by now tapestry would have something out of
the box rather than a custom solution for it... I'm having a look into the
resourceDigestGenerator, but at the moment it isn't the highest thing on my
list.
Geoff Callender-2 wrote:
>
> Ouch, now I get it. WEB-INF and all its contents are in fact visible,
> directly below yourapp/assets/ctx/nnnnnnnnnnnnnnnn/, and it's not hard
> to find out the value of nnnnnnnnnnnnnnnn.
>
> Suggestions anyone?
>
--
View this message in context: http://www.nabble.com/-T5--Security-of-files-in-the-classpath-tp11816097p24981387.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Geoff Callender <ge...@gmail.com>.
Ouch, now I get it. WEB-INF and all its contents are in fact visible,
directly below yourapp/assets/ctx/nnnnnnnnnnnnnnnn/, and it's not hard
to find out the value of nnnnnnnnnnnnnnnn.
Suggestions anyone?
On 15/08/2009, at 10:34 AM, kartweel wrote:
>
> 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<rh...@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
>>>>>> <fa...@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-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by kartweel <rh...@exemail.com.au>.
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<rh...@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
>>>>> <fa...@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-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Geoff Callender <ge...@gmail.com>.
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<rh...@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
>>>> <fa...@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-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by "Juan E. Maya" <ma...@gmail.com>.
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<rh...@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
>>> <fa...@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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by kartweel <rh...@exemail.com.au>.
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
>> <fa...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Robert Zeigler <ro...@scazdl.org>.
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
> <fa...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 03 Aug 2007 10:03:37 -0300, Francois Armand <fa...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Francois Armand <fa...@linagora.com>.
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.
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 ;)
--
Francois Armand
Etudes & Développements J2EE
LINAGORA SA - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
InterLDAP - http://interldap.org
FederID - http://www.federid.org/
Open Source identities management and federation
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 03 Aug 2007 05:33:55 -0300, Robert Zeigler <ro...@scazdl.org>
wrote:
> Nope. Zero configuration necessary for the basic functionality.
> Keep in mind, however, that the default configuration is pretty
> restrictive, since
> it is whitelist-based, and the only entries added by default are the
Would a black list intead of a white list better? I suppose there are less
files to hide than files to allow access.
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Robert Zeigler <ro...@scazdl.org>.
Nope. Zero configuration necessary for the basic functionality.
Keep in mind, however, that the default configuration is pretty
restrictive, since
it is whitelist-based, and the only entries added by default are the
assets that
come "out of the box" with tapestry (tapestry.css, tapestry.js, etc.).
So, you can either contribute a custom AssetPathAuthorizer
(if you don't like the default whitelist strategy...) or you can
contribute to the whitelist authorizer.
For instance, I'm using the jscalendar component (http://
code.google.com/p/tapestry5-jscalendar/
personally using a modified version that is compatible with
T5.0.5...), so I needed to make the assets it uses
available, so I have something like the following in my app module:
public static void contributeWhitelistAuthorizer(
Configuration<String> conf,
@Symbol("net.keso.ted.jscalendarscript.path") String
jscalendarPath) {
conf.add(jscalendarPath +"/calendar-blue.css");
conf.add(jscalendarPath + "/calendar.js");
conf.add(jscalendarPath + "/lang/calendar-en.js");
conf.add(jscalendarPath + "/calendar-setup.js");
conf.add(jscalendarPath + "/button-image.png");
}
Robert
PS: Noticed that I didn't mention the maven artifactId, etc. before
when I mentioned putting it into the maven repo...
groupId: com.saiwaisolutions
artifactId: AssetProtectionDispatcher
version: 0.0.1
On Aug 3, 2007, at 8/32:18 AM , Sabine K. wrote:
>
> Hi Robert,
>
> How to implement this component? Is it necessary to register the
> component
> in the appmodule?
>
> Thx
>
> Sabine
>
>
>
> Robert Zeigler wrote:
>>
>> Couple of comments...
>> First, the T5 asset service has the md5 feature. But the default
>> implementation, at the moment, only requires md5 hashing for
>> the .class files. (So, there's not an open door to the class bytes at
>> the moment. ;)
>> Second, I have a T5 app that should be going live in the next few
>> days. So I implemented an extensible AssetProtectorDispatcher. By
>> default, it uses a whitelist strategy, and the default configuration
>> will add the various tapestry assets (default.css, grid's components,
>> etc.) to the whitelist for you.
>> You can download it here:
>> http://www.tapestrycomponents.org/Tassel/app?service=external/
>> ViewComponent&sp=SAssetProtectionDispatcher
>>
>> Or, if you're a maven user, I've got it in a personal maven repo
>> here:
>> http://www.saiwai-solutions.com/maven
>>
>> Cheers.
>>
>> Robert
>>
>> On Jul 27, 2007, at 7/277:54 AM , Chris Lewis wrote:
>>
>>> I'm quite new to Tapestry and just 2 days ago have started working
>>> with Tap 5. I realize the two (4 vs 5) are disparately different,
>>> but one of the things nice about the Tap 4 asset service was the
>>> checksum feature I mentioned that would deny access unless the sum
>>> in the url matched that of the file. My newness to Tap may show
>>> here, but why can't the asset service simply ignore requests for
>>> files that are not marked (@Asset) as assets? I mean doesn't a deny-
>>> all first and allow explicit exceptions strategy seem much more
>>> sane then providing an open door to the whole classpath (class
>>> bytes included??)?
>>>
>>> Robert Zeigler wrote:
>>>>
>>>> Asset service doesn't really need a configuration point here, imo.
>>>> You can already make contributions to services that would allow
>>>> you to implement this sort of content filtering.
>>>> For instance, you could contribute a RequestFilter. Alternatively,
>>>> you could contribute a Dispatcher to teh MasterDispatcher service.
>>>> Contributions to MasterDispatcher are ordered, so you can
>>>> contribute your "AssetBlockerDispatcher" before the asset service,
>>>> intercept requests to "forbidden" assets,
>>>> and respond appropriately. You could then make your custom
>>>> dispatcher (or request filter) configurable in the manner that you
>>>> desire.
>>>> You don't rewrite any of the asset service, you get your content
>>>> filtering, and you can write it as a drop-in module for any new
>>>> projects.
>>>>
>>>> Robert
>>>>
>>>> On Jul 26, 2007, at 7/266:18 PM , Daniel Jue wrote:
>>>>
>>>>> Thiago, my apologies. You are correct. I would think this is
>>>>> big a
>>>>> problem if you can't hide important files from users!
>>>>>
>>>>> Dan
>>>>>
>>>>> On 7/26/07, Thiago H de Paula Figueiredo <th...@gmail.com>
>>>>> wrote:
>>>>>> On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue
>>>>>> <te...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi, Just don't put configuration resources there.
>>>>>>
>>>>>> I'm not sure you had understood what I've said.
>>>>>>
>>>>>> My hibernate.cfg.xml is in /src/main/resources. So it is
>>>>>> copied by
>>>>>> Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And
>>>>>> anything in
>>>>>> the classpath, as far as I can see, is accessible via
>>>>>> <applicatiourl>/assets. As many frameworks expect their
>>>>>> configuration
>>>>>> files to be in the classpath, I think we have a little, easy to
>>>>>> solve
>>>>>> problem here. :)
>>>>>>
>>>>>> Thiago
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> --
>>>>>> --
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> --
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/-T5--Security-
> of-files-in-the-classpath-tf4153267.html#a11978578
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by "Sabine K." <la...@gmail.com>.
Hi Robert,
How to implement this component? Is it necessary to register the component
in the appmodule?
Thx
Sabine
Robert Zeigler wrote:
>
> Couple of comments...
> First, the T5 asset service has the md5 feature. But the default
> implementation, at the moment, only requires md5 hashing for
> the .class files. (So, there's not an open door to the class bytes at
> the moment. ;)
> Second, I have a T5 app that should be going live in the next few
> days. So I implemented an extensible AssetProtectorDispatcher. By
> default, it uses a whitelist strategy, and the default configuration
> will add the various tapestry assets (default.css, grid's components,
> etc.) to the whitelist for you.
> You can download it here:
> http://www.tapestrycomponents.org/Tassel/app?service=external/
> ViewComponent&sp=SAssetProtectionDispatcher
>
> Or, if you're a maven user, I've got it in a personal maven repo here:
> http://www.saiwai-solutions.com/maven
>
> Cheers.
>
> Robert
>
> On Jul 27, 2007, at 7/277:54 AM , Chris Lewis wrote:
>
>> I'm quite new to Tapestry and just 2 days ago have started working
>> with Tap 5. I realize the two (4 vs 5) are disparately different,
>> but one of the things nice about the Tap 4 asset service was the
>> checksum feature I mentioned that would deny access unless the sum
>> in the url matched that of the file. My newness to Tap may show
>> here, but why can't the asset service simply ignore requests for
>> files that are not marked (@Asset) as assets? I mean doesn't a deny-
>> all first and allow explicit exceptions strategy seem much more
>> sane then providing an open door to the whole classpath (class
>> bytes included??)?
>>
>> Robert Zeigler wrote:
>>>
>>> Asset service doesn't really need a configuration point here, imo.
>>> You can already make contributions to services that would allow
>>> you to implement this sort of content filtering.
>>> For instance, you could contribute a RequestFilter. Alternatively,
>>> you could contribute a Dispatcher to teh MasterDispatcher service.
>>> Contributions to MasterDispatcher are ordered, so you can
>>> contribute your "AssetBlockerDispatcher" before the asset service,
>>> intercept requests to "forbidden" assets,
>>> and respond appropriately. You could then make your custom
>>> dispatcher (or request filter) configurable in the manner that you
>>> desire.
>>> You don't rewrite any of the asset service, you get your content
>>> filtering, and you can write it as a drop-in module for any new
>>> projects.
>>>
>>> Robert
>>>
>>> On Jul 26, 2007, at 7/266:18 PM , Daniel Jue wrote:
>>>
>>>> Thiago, my apologies. You are correct. I would think this is big a
>>>> problem if you can't hide important files from users!
>>>>
>>>> Dan
>>>>
>>>> On 7/26/07, Thiago H de Paula Figueiredo <th...@gmail.com> wrote:
>>>>> On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue
>>>>> <te...@gmail.com> wrote:
>>>>>
>>>>> > Hi, Just don't put configuration resources there.
>>>>>
>>>>> I'm not sure you had understood what I've said.
>>>>>
>>>>> My hibernate.cfg.xml is in /src/main/resources. So it is copied by
>>>>> Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And
>>>>> anything in
>>>>> the classpath, as far as I can see, is accessible via
>>>>> <applicatiourl>/assets. As many frameworks expect their
>>>>> configuration
>>>>> files to be in the classpath, I think we have a little, easy to
>>>>> solve
>>>>> problem here. :)
>>>>>
>>>>> Thiago
>>>>>
>>>>> -------------------------------------------------------------------
>>>>> --
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/-T5--Security-of-files-in-the-classpath-tf4153267.html#a11978578
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Robert Zeigler <ro...@scazdl.org>.
Couple of comments...
First, the T5 asset service has the md5 feature. But the default
implementation, at the moment, only requires md5 hashing for
the .class files. (So, there's not an open door to the class bytes at
the moment. ;)
Second, I have a T5 app that should be going live in the next few
days. So I implemented an extensible AssetProtectorDispatcher. By
default, it uses a whitelist strategy, and the default configuration
will add the various tapestry assets (default.css, grid's components,
etc.) to the whitelist for you.
You can download it here:
http://www.tapestrycomponents.org/Tassel/app?service=external/
ViewComponent&sp=SAssetProtectionDispatcher
Or, if you're a maven user, I've got it in a personal maven repo here:
http://www.saiwai-solutions.com/maven
Cheers.
Robert
On Jul 27, 2007, at 7/277:54 AM , Chris Lewis wrote:
> I'm quite new to Tapestry and just 2 days ago have started working
> with Tap 5. I realize the two (4 vs 5) are disparately different,
> but one of the things nice about the Tap 4 asset service was the
> checksum feature I mentioned that would deny access unless the sum
> in the url matched that of the file. My newness to Tap may show
> here, but why can't the asset service simply ignore requests for
> files that are not marked (@Asset) as assets? I mean doesn't a deny-
> all first and allow explicit exceptions strategy seem much more
> sane then providing an open door to the whole classpath (class
> bytes included??)?
>
> Robert Zeigler wrote:
>>
>> Asset service doesn't really need a configuration point here, imo.
>> You can already make contributions to services that would allow
>> you to implement this sort of content filtering.
>> For instance, you could contribute a RequestFilter. Alternatively,
>> you could contribute a Dispatcher to teh MasterDispatcher service.
>> Contributions to MasterDispatcher are ordered, so you can
>> contribute your "AssetBlockerDispatcher" before the asset service,
>> intercept requests to "forbidden" assets,
>> and respond appropriately. You could then make your custom
>> dispatcher (or request filter) configurable in the manner that you
>> desire.
>> You don't rewrite any of the asset service, you get your content
>> filtering, and you can write it as a drop-in module for any new
>> projects.
>>
>> Robert
>>
>> On Jul 26, 2007, at 7/266:18 PM , Daniel Jue wrote:
>>
>>> Thiago, my apologies. You are correct. I would think this is big a
>>> problem if you can't hide important files from users!
>>>
>>> Dan
>>>
>>> On 7/26/07, Thiago H de Paula Figueiredo <th...@gmail.com> wrote:
>>>> On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue
>>>> <te...@gmail.com> wrote:
>>>>
>>>> > Hi, Just don't put configuration resources there.
>>>>
>>>> I'm not sure you had understood what I've said.
>>>>
>>>> My hibernate.cfg.xml is in /src/main/resources. So it is copied by
>>>> Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And
>>>> anything in
>>>> the classpath, as far as I can see, is accessible via
>>>> <applicatiourl>/assets. As many frameworks expect their
>>>> configuration
>>>> files to be in the classpath, I think we have a little, easy to
>>>> solve
>>>> problem here. :)
>>>>
>>>> Thiago
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Chris Lewis <ch...@bellsouth.net>.
I'm quite new to Tapestry and just 2 days ago have started working with
Tap 5. I realize the two (4 vs 5) are disparately different, but one of
the things nice about the Tap 4 asset service was the checksum feature I
mentioned that would deny access unless the sum in the url matched that
of the file. My newness to Tap may show here, but why can't the asset
service simply ignore requests for files that are not marked (@Asset) as
assets? I mean doesn't a deny-all first and allow explicit exceptions
strategy seem much more sane then providing an open door to the whole
classpath (class bytes included??)?
Robert Zeigler wrote:
>
> Asset service doesn't really need a configuration point here, imo.
> You can already make contributions to services that would allow you to
> implement this sort of content filtering.
> For instance, you could contribute a RequestFilter. Alternatively, you
> could contribute a Dispatcher to teh MasterDispatcher service.
> Contributions to MasterDispatcher are ordered, so you can contribute
> your "AssetBlockerDispatcher" before the asset service, intercept
> requests to "forbidden" assets,
> and respond appropriately. You could then make your custom dispatcher
> (or request filter) configurable in the manner that you desire.
> You don't rewrite any of the asset service, you get your content
> filtering, and you can write it as a drop-in module for any new projects.
>
> Robert
>
> On Jul 26, 2007, at 7/266:18 PM , Daniel Jue wrote:
>
>> Thiago, my apologies. You are correct. I would think this is big a
>> problem if you can't hide important files from users!
>>
>> Dan
>>
>> On 7/26/07, Thiago H de Paula Figueiredo <th...@gmail.com> wrote:
>>> On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue <te...@gmail.com>
>>> wrote:
>>>
>>> > Hi, Just don't put configuration resources there.
>>>
>>> I'm not sure you had understood what I've said.
>>>
>>> My hibernate.cfg.xml is in /src/main/resources. So it is copied by
>>> Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And
>>> anything in
>>> the classpath, as far as I can see, is accessible via
>>> <applicatiourl>/assets. As many frameworks expect their configuration
>>> files to be in the classpath, I think we have a little, easy to solve
>>> problem here. :)
>>>
>>> Thiago
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Chris Lewis <ch...@bellsouth.net>.
I just tried this on the tap 5 tutorial. Requesting the asset service
via /assests (http://localhost:8080/tapestry-tutorial1/assets/)
basically gives you a classpath listing, much like directory index. I
see log4j.properties and org. I can download the log4j - scary - and can
navigate through the classpath as if it where a filesystem. When I tried
to download class bytes for the Start page class
(http://localhost:8080/tapestry-tutorial1/assets/org/apache/tapestry/tutorial/pages/Start.class),
I get 403 and a message about the digest in the request not matching.
So somewhere in there is some sanity, but why does this not apply to
log4/hibernate/etc configurations (maybe b/c they are text??), and why
does the service allow me to effectively browse the classpath?
Anyway, those are my pokings and findings. It seems like this may be
something left in for debugging but should certainly be fixed.
chris
Thiago H de Paula Figueiredo wrote:
> On Thu, 26 Jul 2007 23:20:50 -0300, Robert Zeigler
> <ro...@scazdl.org> wrote:
>
>> Asset service doesn't really need a configuration point here, imo.
>> You can already make contributions to services that would allow you
>> to implement this sort of content filtering.
>
> I agree up to a point. It's a concern that almost all projects have,
> so the framework could (and should) provide an easy way to solve, be
> it some configuration point in AssetService or another dispatcher
> provided by Tapestry.
>
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 26 Jul 2007 23:20:50 -0300, Robert Zeigler <ro...@scazdl.org>
wrote:
> Asset service doesn't really need a configuration point here, imo.
> You can already make contributions to services that would allow you to
> implement this sort of content filtering.
I agree up to a point. It's a concern that almost all projects have, so
the framework could (and should) provide an easy way to solve, be it some
configuration point in AssetService or another dispatcher provided by
Tapestry.
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Robert Zeigler <ro...@scazdl.org>.
Asset service doesn't really need a configuration point here, imo.
You can already make contributions to services that would allow you
to implement this sort of content filtering.
For instance, you could contribute a RequestFilter. Alternatively,
you could contribute a Dispatcher to teh MasterDispatcher service.
Contributions to MasterDispatcher are ordered, so you can contribute
your "AssetBlockerDispatcher" before the asset service, intercept
requests to "forbidden" assets,
and respond appropriately. You could then make your custom
dispatcher (or request filter) configurable in the manner that you
desire.
You don't rewrite any of the asset service, you get your content
filtering, and you can write it as a drop-in module for any new
projects.
Robert
On Jul 26, 2007, at 7/266:18 PM , Daniel Jue wrote:
> Thiago, my apologies. You are correct. I would think this is big a
> problem if you can't hide important files from users!
>
> Dan
>
> On 7/26/07, Thiago H de Paula Figueiredo <th...@gmail.com> wrote:
>> On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue
>> <te...@gmail.com> wrote:
>>
>> > Hi, Just don't put configuration resources there.
>>
>> I'm not sure you had understood what I've said.
>>
>> My hibernate.cfg.xml is in /src/main/resources. So it is copied by
>> Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And
>> anything in
>> the classpath, as far as I can see, is accessible via
>> <applicatiourl>/assets. As many frameworks expect their configuration
>> files to be in the classpath, I think we have a little, easy to solve
>> problem here. :)
>>
>> Thiago
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Daniel Jue <te...@gmail.com>.
Thiago, my apologies. You are correct. I would think this is big a
problem if you can't hide important files from users!
Dan
On 7/26/07, Thiago H de Paula Figueiredo <th...@gmail.com> wrote:
> On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue <te...@gmail.com> wrote:
>
> > Hi, Just don't put configuration resources there.
>
> I'm not sure you had understood what I've said.
>
> My hibernate.cfg.xml is in /src/main/resources. So it is copied by
> Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And anything in
> the classpath, as far as I can see, is accessible via
> <applicatiourl>/assets. As many frameworks expect their configuration
> files to be in the classpath, I think we have a little, easy to solve
> problem here. :)
>
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue <te...@gmail.com> wrote:
> Hi, Just don't put configuration resources there.
I'm not sure you had understood what I've said.
My hibernate.cfg.xml is in /src/main/resources. So it is copied by
Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And anything in
the classpath, as far as I can see, is accessible via
<applicatiourl>/assets. As many frameworks expect their configuration
files to be in the classpath, I think we have a little, easy to solve
problem here. :)
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Daniel Jue <te...@gmail.com>.
Hi, Just don't put configuration resources there. Here's what I use
(since I wrote it up heheh):
http://wiki.apache.org/tapestry/Tapestry5WhereToStoreConfigurationResources
http://wiki.apache.org/tapestry/Tapestry5WhereToStoreExternalResources
On 7/26/07, Thiago H de Paula Figueiredo <th...@gmail.com> wrote:
> Hi!
>
> I'm developing a Tapestry 5 application and I was looking at access to
> assets via URLs. I typed http://localhost:8080/assets/tapestry/default.css
> to take a look at T5 default CSS values.
>
> Then I typed http://localhost:8080/assets/hibernate.cfg.xml . . . and it
> showed that file. It's a security flaw.
> Is there any measure already implemented against this kind of attack? It
> would be very nice if we could block asset access to files and folders
> through some Tapestry-IoC contribution. ;)
>
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org