You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by RR <se...@gmail.com> on 2005/09/02 18:07:40 UTC

render time element removal question

I'm wondering if anyone has impemented a security model that requires 
dynamic (render-time) removal of certain HTML elements? And if so, how hefty 
was the work? I need to remove elements at render time based upon roles and 
rights and *do not* want to wrap all of the secure elements in conditionals. 
Rather, I'd wish to determine at render time the necessity of removing 
certain elements and simply not render them.

TIA,
-RR-

Re: render time element removal question

Posted by Nicholoz Koka Kiknadze <22...@gmail.com>.
It's rather a question as I'm yet not quite at home with Tapestry insides, 
but...

Is not it possible to use some kind of custom renderer that will be doing 
all those security checks? It would have been the first thing I'd have 
started digging into.

Re: render time element removal question

Posted by RR <se...@gmail.com>.
I had considered this approach and appreciate the feedback. 

At this point I'm trying to evaulate whether it's worth the effort to modify 
what Tapestry code I need to behave as I've described, or to simply wrap all 
the secure elements in conditionals or a component (as you have suggested). 
The latter seems to be a lot more work, considering I have ~200 elements. On 
the contrary, if I just evaluated each element's id upon render and 
validated access, it'd be conceptually easy to simply not render it. 
However, I haven't yet even peeked at any render code. Hence my solicitation 
for suggestions, ideas and experiences.


On 9/2/05, robertz@scazdl.org <ro...@scazdl.org> wrote:
> 
> To be honest, personally, I don't think that approach is really going to
> mix well with tapestry. As was mentioned by HLS in a recent thread, you
> should consider pages at runtime as immutable. Removing elements will
> prove problematic, I think.
> An approach I used was to create a sort of "inRole" component. It takes
> as parameters either a requisite permission name or an object for which
> permission is required. It's essentially an "if" wrapper, but has the
> advantage of centralizing the render-oriented permission logic to a single
> component.
> You could also create custom wrappers around any components. So you
> could, for instance, create a "SecureTable" component which wraps a table
> component, adds parameters related to permission checking, and
> conditionally renders the component. Then you could use your SecureTable
> just like table, and still have your dynamic behavior.... static
> structure, dynamic behavior. :)
> 
> Robert
> 
> > I'm wondering if anyone has impemented a security model that requires
> > dynamic (render-time) removal of certain HTML elements? And if so, how
> > hefty
> > was the work? I need to remove elements at render time based upon roles
> > and
> > rights and *do not* want to wrap all of the secure elements in
> > conditionals.
> > Rather, I'd wish to determine at render time the necessity of removing
> > certain elements and simply not render them.
> >
> > TIA,
> > -RR-
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> 
>

Re: render time element removal question

Posted by ro...@scazdl.org.
To be honest, personally, I don't think that approach is really going to
mix well with tapestry.  As was mentioned by HLS in a recent thread, you
should consider pages at runtime as immutable.  Removing elements will
prove problematic, I think.
An approach I used was to create a sort of "inRole" component.  It takes
as parameters either a requisite permission name or an object for which
permission is required.  It's essentially an "if" wrapper, but has the
advantage of centralizing the render-oriented permission logic to a single
component.
You could also create custom wrappers around any components.  So you
could, for instance, create a "SecureTable" component which wraps a table
component, adds parameters related to permission checking, and
conditionally renders the component. Then you could use your SecureTable
just like table, and still have your dynamic behavior.... static
structure, dynamic behavior. :)

Robert

> I'm wondering if anyone has impemented a security model that requires
> dynamic (render-time) removal of certain HTML elements? And if so, how
> hefty
> was the work? I need to remove elements at render time based upon roles
> and
> rights and *do not* want to wrap all of the secure elements in
> conditionals.
> Rather, I'd wish to determine at render time the necessity of removing
> certain elements and simply not render them.
>
> TIA,
> -RR-
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org