I'm curious why storing a list in hidden fields, even as ids, isn't
considered a huge security hole. Doesn't it seem like it is just
inviting users to manipulate their application into letting them do
things to entities they shouldn't have access to, etc. I use volatile
wherever I can, despite the risk of stale link exceptions, precisely
for this reason. It is either that or put a ton of logic into the
converter to ensure that only the correct values are iterated over,
and given that business rules may be different from loop to loop, it
may even mean implementing different converter logic for every loop
(or significant fraction of them) in the application.
I am particularly concerned by storing the precomputed values of
conditionals in hidden fields. If you have code that says something
like some code
here it would be all to easy to manipulate the client into
rewinding with different authorization credentials than the page was
rendered with.
So basically, my strategy is to use volatile="true" in almost all
conditionals and loops. I am at higher risk of stale link errors, but
much lower risk of security breach and malicious users. The one case
that forces me to use a non-volatile conditional or loop is when a
field from earlier in the page is part of the condition. Since that
value can easily change when it is rewound prior to the conditional, I
am forced to either implement logic in the page which stores the prior
value when the set method is called, or use a non-volatile
conditional.
--sam
On 3/13/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
I'm not certain this change happened from 4.1 to 4.1.1 as I'm pretty
sure I never made it. Maybe from 3 -> 4 ?
The list is stored in the form ~specifically~ so that it does match
exactly on render/rewind as anything else would be un-predictable .
You can set volatile=true on your list -> but if you are using
hibernate you really want to make use of the converter parameter to
encode the very minimum amount of data necessary to re-constitute your
entity list.
On 3/12/07, Robert J. Walker <[EMAIL PROTECTED]> wrote:
> I just upgraded from Tapestry 4.1 to 4.1.1. Now I'm having some problems with
the For component. It seems that it was changed so that it stores the source list
in hidden fields in the page and uses the stored version on rewind. I can
understand why this might be useful, since it could be problematic if the source
list changed on you between render and rewind. That being said, it causes two
really big problems for me:
>
> 1. The download size of the page just got enormous.
>
> 2. The source list contains Hibernate entities, which are now detached on the
rewind, causing errors.
>
> What I really want is the old behavior, which is to reload the list every
time. I'll deal with the consequences of the list changing. Is there some way to
get that behavior back, short of making my own component that subclasses ForBean
and overrides getData()?
>
> Robert J. Walker
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
