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 <span jwcid="@If" condition="isAuthorized(...)">some code here</span> 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]