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 -~----------~----~----~----~------~----~------~--~---
