[development] more consistency in theme functions and output concepts.

[Bèr Kessels]

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');
theme_pimp($string) {
  return '<span class="bling">'. t($string) .'</span>';
}
vs:
$bling = t('bling bling')
theme('pimp', $bling);
theme_pimp($string) {
  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.

Bèr