[development] more consistency in theme functions and output
ber at webschuur.com
Thu May 11 12:26:46 UTC 2006
Op woensdag 10 mei 2006 13:30, schreef Gerhard Killesreiter:
> > So I agree that the theme layer might not be the best place, but fact
> > remains that we need a *central* place, not?
> It is hard to do that. Actually, there is a way to get rid of XSS once
> and for all: Filter your complete output through filter_admin_xss in
> your theme. :p
Yes. If that function is smart enough filtering for ONLY XSS should definately
be done in the very end. It now also tries to fiddle with HTML so it cannot
be used like this, yet.
However, lets forget about XSS, but focus on HTML itself. It is not at all
hard to filter this in one place. In fact, Ruby in Rails (yes, there we go
again) has a very clean, clear, and thus *secure* concept.
input ->| RoR app |->| view |-> output
RoR filters input on its model/controller level. This has very little to do
with XSS/HTML filtering, but all with cleaning out stuff to avoid SQL
injection etc. Result: You need not bother about all that, becuase on the
very front-end there was taken care of it (obviously this can potentially be
overriden if you really want to).
then RoR "does stuff" and pipes the data to the views level.
That is the place where one filters the output. Not *inside* the
model/controllers, but in the view, the output. In drupal you can see the
theme as the view layer.
So yes, it puts responsibility on the ones printing stuff to the screen, but
the fact that it is 100% clear who is responsible and where the stuff takes
place, makes it very secure.
We might need some better helper methods though. because "filtering" in RoR is
nothing more then <%=h @foo %> (in PHP <?php print h($foo) ?> )
But wheter or not its the views layer where output sanitizing takes place, we
still need a central layer to do that sanitizing. It could even be automated
and placed in the theme engines. Or we could agree that it happens /just/
before calling theme functions.
Having sometimes the theme layer sanitizing, sometimes the controller level is
asking for problems. "no, your theme forgets to call the filter" "hmm, I
thought the module did the filtering".
Or "woa, that is a big security hole, strange, I though the theme function did
the check_clean()", "nope, it was there, but we moved that into the modules".
> > IMO having it "all over the place" is worse then having it in a theme
> > layer where we say "themes are the ones to filter/sanitize all output".
> I am very uncomfortable with this. Also, this will add complexity to the
> themes while many people try to remove complexity.
> I can replace any themed function by anything else so I sure can just
> change the strings.
What I propose is:
theme('pimp', 'bling bling');
return '<span class="bling">'. t($string) .'</span>';
$bling = t('bling bling')
return '<span class="bling">'. $string .'</span>';
We mix up both right now. Though the fist one is the least used, it does
happen a lot. I am proposing to choose ONE and work towards that.
More information about the development