On 27.09.11 07:03, Christian Stocker wrote: > Hi again > > I just had the idea for a 4th option. Won't be less controversy, but > it's backwards and forwards compatible. > > 4) use a php ini setting in PHP 5.3
So, here's a patch for PHP_5_3 with this approach https://gist.github.com/1259520 can anyone confirm, that this is ok to be put in PHP_5_3 branch? (regarding ABI change and maybe similar issues I was not thinking about) chregu > > I know, we try to avoid that as much as possible. BUT > > * It will only be in 5.3, not even committed to 5.4 > * If you don't have the ini setting, your XSLT can't write files, the > error will be pretty obvious. If you just read and transform, nothing > will or has to change > * Only a very very very small fraction will need to set this ini setting > > The code for enable writing again, which would work in 5.0 - 5.4+ looks > like this. With my first proposal, I'd need much more if/else to make my > code work on 5.3.8-/5.3.9+/5.4+ > > *** > $xsl = new XSLTProcessor(); > > //if you want to write from within the XSLT > $oldvalini = ini_set("xsl_security_prefs",XSL_SECPREFS_NONE); > if (version_compare(PHP_VERSION,'5.4',">=")) { > $oldval = $xsl->setSecurityPreferences(XSL_SECPREFS_NONE); > } > > $xsl->transformToXml(...); > > //go back to the old setting. Better safe than sorry > ini_set("xsl_security_prefs",$oldvalini); > if (version_compare(PHP_VERSION,'5.4',">=")) { > $xsl->setSecurityPreferences($oldval); > } > *** > > chregu > > > > > On 26.09.11 19:59, Christian Stocker wrote: >> Hi >> >> Some weeks ago I wrote a patch to disable writing from within XSLT >> templates. That patch is now in 5.4 but wasn't accepted in PHP 5.3 since >> it changed a struct in the header file. >> >> I have now I new patch which doesn't need that changing in the struct, >> but I need a new .h file from libxslt. >> >> https://gist.github.com/3d3d3c3418236f748118 (unfinished patch, just a >> proof of concept, but the basics are there) >> >> Can anybody tell me, if that still breaks binary compatibility for >> extensions or if that would be ok? >> >> Then a more general question: >> >> There are now 2 ways to enable write access again (in 5.4). Via an >> additional optional parameter to the transform methods (this works with >> the patch above in 5.3 also) or via the new 5.4 only method >> ->setSecurityPrefs(). The former is from a clean API point of view not >> nice, adding more and more optional parameters to methods is the ticket >> to hell usually. But I can't come up with a better solution for 5.3 >> without breaking the ABI. And since it's somehow a security issue, I >> would sleep better a lot, if we have a proper patch for 5.3 as well. >> >> To keep BC, I can't just delete the optional parameter again for 5.4, >> that would make portable code a pain. OTOH, the way I did it know, it >> breaks BC with PHP < 5.3.9, if you want to enable write access in xslt >> templates in PHP 5.3.9+. If you don't need that, which is maybe 99.9% of >> all cases, BC is kept for since PHP 5.0 until much after PHP 5.4 :) >> >> So there are 3 options >> >> 1) leave it like it is currently. No write protection in 5.3, only in 5.4 >> 2) Have 2 ways to enable write access from 5.3.9+ and 5.4. >> 3) Remove the ->setSecurityPrefs() in 5.4, so there's only one way to >> enable write access again, but it's the nasty one from a clean API POV. >> >> For 2) and 3), code with those new options won't work anymore in 5.3.8- >> (but you can check it in PHP user land and treat it differently), but >> you get write protection automatically >> >> Again, all this will only affect a very small fraction of users, those >> who legitimately wrote files from within XSLT. >> >> Any opinions? Me personally would like to have it in PHP 5.3 (or at >> least offer a proper patch). >> >> chregu >> > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
