Fabien, This is a good solution. 'bc' should fallback to 'off' and 'both' should fallback to 'on', with a warning. Like that, nothing is broken.
Besides, the escaping chapter will be much easier to explain ;) François 2008/4/2, Fabien POTENCIER <[EMAIL PROTECTED]>: > > > Francois Zaninotto wrote: > > Devs, > > > > From what I understand, r8201 sets the default escaping to 'off'. And > > either I don't fully understand it, or it will break a lot of > > applications with no possibility to upgrade, and for several reasons: > > > > - Some plugins use $sf_data->getRaw() in templates to deal with > > escaping properly when required. But with escaping set to off by > > default, $sf_data doesn't exist, does it? So these plugins will break. > > And this will force plugin writers to review their code entirely to make > > it work in both cases (either by detecting escaping before every escape, > > or by providing two versions of the plugins). This is such a lot of work > > that I'm pretty sure many developers will not do it, reducing the number > > of 1.1 compatible plugins drastically. > > > You're right, $sf_data does not exist if the escaping strategy is set to > off. So, plugin writers definitely need to deal with the escaping > strategy, which is far from ideal. I've checked all plugins published on > the symfony wiki, and surprisingly only 10 plugins use $sf_data with a > total of 34 occurrences! Still, we need to address this in the framework. > > Before the r8201 changeset, we had: > > - bc: > - $sf_data: escaped > - "normal" vars: unescaped > - off: > - $sf_data: not available > - "normal" vars: unescaped > - on: > - $sf_data: escaped > - "normal" vars: not available > - both: > - $sf_data: escaped > - "normal" vars: escaped > > Now, let's see what it meant for plugin developers: > > - if they use $sf_data and "normal" vars: > - compatible: bc, both > - unable to work with on and off > > - if they only use $sf_data: > - compatible: bc, both, on > - unable to work with off > > - if they only use "normal" vars: > - compatible: bc, both, off > - unable to work with on > > So, only bc and both strategies were usable because they worked in all > cases (with different level of security). > > After changeset r8201, except the removal of bc, everything else is just > the same. And for plugin developers: > > - if they use $sf_data and "normal" vars: > - compatible: both > - unable to work with on and off > > - if they only use $sf_data: > - compatible: both, on > - unable to work with off > > - if they only use "normal" vars: > - compatible: both, off > - unable to work with on > > So, now the only "usable" setting is both. > > What does it mean? It means that "off" and "on" settings were and are > not really good options compatibility wise. > > My proposal: We provide 2 settings: on and off. > > - off: > - $sf_data: unescaped > - "normal" vars: unescaped > - on: > - $sf_data: escaped > - "normal" vars: escaped > > I think it resolves all problems and everything is clearer and easier to > understand. > > > Fabien > > > > > > - Applications that currently rely on 'bc' will get an exception when > > upgrading. Now, if they do want to use some pieces of code with > > escaping, they will have no choice but to switch to 'both', and that > > will probably break their applications in a lot of places with no easy > > upgrade path. > > > > So my question is: Is the purpose of improved security a good enough > > reason to make the upgrade to 1.1 much harder? > > > > François > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
