Yii Framework 2.0.0 GA(yiiframework.com) |
Yii Framework 2.0.0 GA(yiiframework.com) |
This is just a minor complaint, but it's so pervasive among web frameworks that I must complain yet again.
According to the documentation for Yii 2.0, the recommended way to output a variable to a web page is:
<?= Html::encode($var) ?>
<?= $var ?>
But why does every framework (and many template engines) insist on telling you to call a specific function in the template in order to get XSS protection? HTML escaping should be turned on by default, by whatever means possible.
The simplest template syntax should also be the most secure, not the other way around. Because sooner or later, somebody is going to forget to call that function.
Auto-escaping also saves a lot of clutter in templates, since there are usually only a few places in any given page (usually the content of a post) where HTML content needs to be printed unescaped (but filtered, of course).
Some frameworks escape everything by default and only allow you to print raw HTML if you add a "noescape" flag. This is better, but some of them only do this if you turn on some sort of "autoescape" flag at the top. This is just as bad, since it is insecure by default.
One might point out that not all escaping is the same, since different escaping rules apply in different contexts. But do we really have no way to detect, when parsing and compiling a template, which context we're currently in?
XSS protection in modern template engines should be opt-out, not opt-in. Otherwise they have no right to claim XSS protection as a feature.
But the price you pay for that of course is no longer working directly in PHP but a templating language with its own syntax (for instance, array shorthand in Twig templates [] has worked since I don't know when but only recently has PHP gotten around to supporting it) which has to be parsed, and partially compiled into PHP classes.
Non-PHP frameworks, on the other hand, really have no excuse.
You're talking about the `[]` short-hand for arrays, right? That was released in version 5.4, in March 2012, I wouldn't really say that's "recent", at least in my opinion.
1. You're no longer using PHP. btw., Yii supports Twig that escapes everything by default. 2. Performancewise it's quite a bit hit.
2. You'll have to escape virtually all the strings that go into the template anyway. So the peformance hit of escaping is almost the same, assuming you don't re-compile the template every single time (which no sane template system does).
That said, I get the sweats when I have to wade into an old Yii-powered app that I wrote. Entirely faults of PHP (lack of symbols, array(...) declarations, semicolon-itis) and my lack of experience back then (no testing, fat controllers). I do miss the simplicity of deploying a Yii app, and its speed compared to Rails. The creator, Qiang, is a PHP whizz.
Sorry, but those are entirely trivial syntactic issues, and not very interesting at that either...
Lisp, Erlang, and Prolog (sure some other languages I've missed) have direct equivalents to Ruby symbols; they are sometimes referred to as symbols other times as atoms.
Saying they are a trivial syntactic issue just means you don't understand what symbols are.
It's hard to describe why, I think mostly because it feels like it was built and designed by one person who had a lot of experience with other frameworks and knew PHP inside and out.
+1 for opinionated security at the framework/platform level rather at the programmer level, such that security features can be evolved, refined, debugged over time and pushed back upstream, rather than reimplemented from scratch each new project.
You can jump start using the new app templates:
1) https://github.com/yiisoft/yii2-app-basic - simple app
2) https://github.com/yiisoft/yii2-app-advanced - if you need multiple interfaces (frontend/backend/api)
> Alphabetic characters in the fully qualified class name MAY be any combination of lower case and upper case. http://www.php-fig.org/psr/psr-4/
For 1.1 there are some:
https://www.facebook-studio.com/, http://2gis.ru/, http://itop.fm/, https://www.humhub.org/, http://www.x2engine.com/, http://zurmo.org/, https://www.rebilly.com/, http://buildwithcraft.com/
If you put the effort in to learn it thoroughly, you'll be rewarded with an incredibly productive platform that is great not just for getting apps out of the door super quickly, but also provides a secure, scalable foundation which is easy to grow and maintain.
> Symbols persist across multiple requests; this is a big part of why they are so beneficial.
That is still not really useful, PHP throws the entire execution context away after the request has finished. There is no sharing nor anything to persist unless you're doing so with an external data-store.
I mean, you technically could, but it's not what they are used for.
Granted, Ruby's use of symbols is not as pretty as other languages...
What doesn't happen compared to CGI, IIRC, is loading the whole PHP engine from the start for every invocation. But no request specific memory is ever shared between invocations.
Shared-nothing turns out to be really nice for scaling web apps. One of the few things PHP got right from the get-go.
The parent stated, "Sorry, but those are entirely trivial syntactic issues, and not very interesting at that either..."
My point was that symbols/atoms are much more than just a syntactic difference and that they are in fact quite interesting. Chicago Boss, an Erlang framework, takes these ideas to an extreme to push the limits of shared immutable memory on a web server.
http://www.chicagoboss.org/about.htm
I'm not a big fan of the way he trashes pretty much every alternative at the beginning of his description; there are many web frameworks built on many different languages that the market has proved out are sufficiently scalable.
It is however an interesting and different approach that I think we can both agree goes far beyond "trivial syntactic issues".