You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by cordenier christophe <ch...@gmail.com> on 2010/01/06 18:41:44 UTC
FieldTranslatorSourceImpl
Hi,
I am facing a problem related to the design of FieldTranslatorSourceImpl
internal class design.
I would like to adivse one of the method to pass my own modified instance of
Translator, but actually the adivor does'nt work for this method because the
public method (from the interface) is called from the inside... and the one
invoced by the Tapestry other internals is not the one i wan't to decorate
of course :)
Is this a bug or a design principal to secure internal classes ?
Best Regards,
Christophe.
Re: FieldTranslatorSourceImpl
Posted by cordenier christophe <ch...@gmail.com>.
Hi
After all, i will decorate only the
'createDefaultTranslator(ComponentResources resources, String
parameterName)' method and obtain the annotation provider from its
parameters. So i can have access to the annotation associated to the bound
property and get configuration specifics.
I might be wrong, but i think that the code in
'createTranslator(Field field, String overrideId, Messages overrideMessages,
Locale locale, Translator translator)' should be refactored in a private
method, so all the public method declared in interface can be decorated
without the side effects of call to public method from the inside.
Best Regards,
Christophe
2010/1/6 Howard Lewis Ship <hl...@gmail.com>
> I don't know if this qualifies as a bug, I think not ... having a
> service call one of its own methods via its proxy is not unreasonable
> (and should be supported) BUT would not be the normal case and would
> need to see a use case for it (which is why I really like interfaces
> with just one method :-)
>
> What are you actually trying to accomplish, perhaps there is another way?
>
> On Wed, Jan 6, 2010 at 9:41 AM, cordenier christophe
> <ch...@gmail.com> wrote:
> > Hi,
> >
> > I am facing a problem related to the design of FieldTranslatorSourceImpl
> > internal class design.
> >
> > I would like to adivse one of the method to pass my own modified instance
> of
> > Translator, but actually the adivor does'nt work for this method because
> the
> > public method (from the interface) is called from the inside... and the
> one
> > invoced by the Tapestry other internals is not the one i wan't to
> decorate
> > of course :)
> >
> > Is this a bug or a design principal to secure internal classes ?
> >
> > Best Regards,
> > Christophe.
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: FieldTranslatorSourceImpl
Posted by cordenier christophe <ch...@gmail.com>.
I have to admit you are right, next time i will read recommandations
fully... Sorry for annoyance with SQL escaping.
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Encoder.html
BTW it would be interesting to allow developper to advise a service
considering only its interface and not the way the services is implemented.
Be sure I don't mind looking at the source code, because it makes me learn a
lot, but IMHO this kind of developper consideration is important to be taken
into account.
2010/1/7 Thiago H. de Paula Figueiredo <th...@gmail.com>
> Em Thu, 07 Jan 2010 11:36:27 -0200, Andreas Andreou <an...@di.uoa.gr>
> escreveu:
>
>
> I'm not aware what the OWASP recommandations are. When 2 layers serve
>> different goals and one of them is vulnerable, it doesn't make sense to
>> protect the other one - that other layer wouldn't even know what to protect
>> against since it could interoperate with any kind of back-end.
>>
>
> I guess the recommendations are that one layer cannot take for granted that
> the other has done all the needed validations. In other words, each layer
> must do the validations related to the input it takes. Andreas is right when
> it says that one layer needn't protect another layer, specially because one
> doesn't even know how the other is implemented.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, software architect and developer, Ars Machina Tecnologia da
> Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: FieldTranslatorSourceImpl
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 07 Jan 2010 11:36:27 -0200, Andreas Andreou <an...@di.uoa.gr>
escreveu:
> I'm not aware what the OWASP recommandations are. When 2 layers serve
> different goals and one of them is vulnerable, it doesn't make sense to
> protect the other one - that other layer wouldn't even know what to
> protect
> against since it could interoperate with any kind of back-end.
I guess the recommendations are that one layer cannot take for granted
that the other has done all the needed validations. In other words, each
layer must do the validations related to the input it takes. Andreas is
right when it says that one layer needn't protect another layer, specially
because one doesn't even know how the other is implemented.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: FieldTranslatorSourceImpl
Posted by Andreas Andreou <an...@di.uoa.gr>.
I'm not aware what the OWASP recommandations are. When 2 layers serve
different goals and one of them is vulnerable, it doesn't make sense to protect
the other one - that other layer wouldn't even know what to protect
against since
it could interoperate with any kind of back-end.
On Thu, Jan 7, 2010 at 12:46, cordenier christophe
<ch...@gmail.com> wrote:
> Yes i understand and i agree with your point and i have also read the
> security consideration written by Howard on its blog about SQL escaping. But
> we are trying to follow OWASP recommandations and each layer should be
> protected, not only for SQL escaping. While others are already handled by
> Tapestry, this one is important also for older application that do not use
> JPA implementations
>
> 2010/1/7 Thiago H. de Paula Figueiredo <th...@gmail.com>
>
>> Em Wed, 06 Jan 2010 16:51:52 -0200, cordenier christophe <
>> christophe.cordenier@gmail.com> escreveu:
>>
>>
>> Tapestry has a lot of security mechanisms regarding type control, method
>>> events control... but sql escaping is missing, this is my first goal but i
>>> am writing a mechanism with an extensible and configurable list of codec.
>>>
>>
>> IMHO, SQL escaping is something to be done at the persistence layer level,
>> not at the presentation layer (Tapestry).
>> By the way, using some object-relational mapping like Hibernate, JPA or
>> iBatis solves the problem for you, as they do the escaping automatically.
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
>> and instructor
>> Owner, software architect and developer, Ars Machina Tecnologia da
>> Informação Ltda.
>> http://www.arsmachina.com.br
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
--
Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: FieldTranslatorSourceImpl
Posted by cordenier christophe <ch...@gmail.com>.
Yes i understand and i agree with your point and i have also read the
security consideration written by Howard on its blog about SQL escaping. But
we are trying to follow OWASP recommandations and each layer should be
protected, not only for SQL escaping. While others are already handled by
Tapestry, this one is important also for older application that do not use
JPA implementations
2010/1/7 Thiago H. de Paula Figueiredo <th...@gmail.com>
> Em Wed, 06 Jan 2010 16:51:52 -0200, cordenier christophe <
> christophe.cordenier@gmail.com> escreveu:
>
>
> Tapestry has a lot of security mechanisms regarding type control, method
>> events control... but sql escaping is missing, this is my first goal but i
>> am writing a mechanism with an extensible and configurable list of codec.
>>
>
> IMHO, SQL escaping is something to be done at the persistence layer level,
> not at the presentation layer (Tapestry).
> By the way, using some object-relational mapping like Hibernate, JPA or
> iBatis solves the problem for you, as they do the escaping automatically.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, software architect and developer, Ars Machina Tecnologia da
> Informação Ltda.
> http://www.arsmachina.com.br
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: FieldTranslatorSourceImpl
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 06 Jan 2010 16:51:52 -0200, cordenier christophe
<ch...@gmail.com> escreveu:
> Tapestry has a lot of security mechanisms regarding type control, method
> events control... but sql escaping is missing, this is my first goal but
> i am writing a mechanism with an extensible and configurable list of
> codec.
IMHO, SQL escaping is something to be done at the persistence layer level,
not at the presentation layer (Tapestry).
By the way, using some object-relational mapping like Hibernate, JPA or
iBatis solves the problem for you, as they do the escaping automatically.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: FieldTranslatorSourceImpl
Posted by cordenier christophe <ch...@gmail.com>.
Oups, i just figured out that i will not have access to what i need with the
AnnotationProvider provided by FieldTranslatorSource methos :(
2010/1/6 cordenier christophe <ch...@gmail.com>
> My objective is to provide a Translator that will add protection on
> textfield value (sql escaping...), a default escaping mechanism can be
> handled by an override of the StringTranslator. But i would like to add a
> specific configuration in function of annotations provided by the
> application developper on its fields, so i need to access to the annotation
> provider provided by a method in FieldTranslatorSource interface.
>
> Tapestry has a lot of security mechanisms regarding type control, method
> events control... but sql escaping is missing, this is my first goal but i
> am writing a mechanism with an extensible and configurable list of codec.
>
> Best Regards,
> Christophe.
>
> 2010/1/6 Howard Lewis Ship <hl...@gmail.com>
>
> I don't know if this qualifies as a bug, I think not ... having a
>> service call one of its own methods via its proxy is not unreasonable
>> (and should be supported) BUT would not be the normal case and would
>> need to see a use case for it (which is why I really like interfaces
>> with just one method :-)
>>
>> What are you actually trying to accomplish, perhaps there is another way?
>>
>> On Wed, Jan 6, 2010 at 9:41 AM, cordenier christophe
>> <ch...@gmail.com> wrote:
>> > Hi,
>> >
>> > I am facing a problem related to the design of FieldTranslatorSourceImpl
>> > internal class design.
>> >
>> > I would like to adivse one of the method to pass my own modified
>> instance of
>> > Translator, but actually the adivor does'nt work for this method because
>> the
>> > public method (from the interface) is called from the inside... and the
>> one
>> > invoced by the Tapestry other internals is not the one i wan't to
>> decorate
>> > of course :)
>> >
>> > Is this a bug or a design principal to secure internal classes ?
>> >
>> > Best Regards,
>> > Christophe.
>> >
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
Re: FieldTranslatorSourceImpl
Posted by cordenier christophe <ch...@gmail.com>.
My objective is to provide a Translator that will add protection on
textfield value (sql escaping...), a default escaping mechanism can be
handled by an override of the StringTranslator. But i would like to add a
specific configuration in function of annotations provided by the
application developper on its fields, so i need to access to the annotation
provider provided by a method in FieldTranslatorSource interface.
Tapestry has a lot of security mechanisms regarding type control, method
events control... but sql escaping is missing, this is my first goal but i
am writing a mechanism with an extensible and configurable list of codec.
Best Regards,
Christophe.
2010/1/6 Howard Lewis Ship <hl...@gmail.com>
> I don't know if this qualifies as a bug, I think not ... having a
> service call one of its own methods via its proxy is not unreasonable
> (and should be supported) BUT would not be the normal case and would
> need to see a use case for it (which is why I really like interfaces
> with just one method :-)
>
> What are you actually trying to accomplish, perhaps there is another way?
>
> On Wed, Jan 6, 2010 at 9:41 AM, cordenier christophe
> <ch...@gmail.com> wrote:
> > Hi,
> >
> > I am facing a problem related to the design of FieldTranslatorSourceImpl
> > internal class design.
> >
> > I would like to adivse one of the method to pass my own modified instance
> of
> > Translator, but actually the adivor does'nt work for this method because
> the
> > public method (from the interface) is called from the inside... and the
> one
> > invoced by the Tapestry other internals is not the one i wan't to
> decorate
> > of course :)
> >
> > Is this a bug or a design principal to secure internal classes ?
> >
> > Best Regards,
> > Christophe.
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: FieldTranslatorSourceImpl
Posted by Howard Lewis Ship <hl...@gmail.com>.
I don't know if this qualifies as a bug, I think not ... having a
service call one of its own methods via its proxy is not unreasonable
(and should be supported) BUT would not be the normal case and would
need to see a use case for it (which is why I really like interfaces
with just one method :-)
What are you actually trying to accomplish, perhaps there is another way?
On Wed, Jan 6, 2010 at 9:41 AM, cordenier christophe
<ch...@gmail.com> wrote:
> Hi,
>
> I am facing a problem related to the design of FieldTranslatorSourceImpl
> internal class design.
>
> I would like to adivse one of the method to pass my own modified instance of
> Translator, but actually the adivor does'nt work for this method because the
> public method (from the interface) is called from the inside... and the one
> invoced by the Tapestry other internals is not the one i wan't to decorate
> of course :)
>
> Is this a bug or a design principal to secure internal classes ?
>
> Best Regards,
> Christophe.
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org