-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add the "safe" modifier to skip auto_escape #74
base: master
Are you sure you want to change the base?
Conversation
I feel like these safety/autoescape features are silly inside the RainTPL, and should be left to users writing code/themes to filter stuff properly. This includes the sandbox mode, which basicly doesn't guarantee that there won't be an exploit that by-passes that. On top of that, it's just making RainTPL more bloated, and less speedy. I personally use this lib with sandbox and auto_escape disabled, and deal with that myself where I need to. |
Well, if it should be left to users writing code/themes to filter stuff properly, then apparently the auto escape feature is totally useless, since you can't turn it off in runtime, and turns out to be that you MUST turn it off and handle all by yourself. |
This is an interesting pull request, I needed this functionality. @xPaw sandbox and auto_escape have different responsibility, the first should make the code safe by PHP injection in those project where you load templates from untrusted sources, the second instead is to keep the page safe from javascript injection, read XSS, so for example blog, forums should have auto_escape always on. The sandbox it still need a great tune up. I'll check your code and merge it to master. |
I think, It's better to do the opposite, with an |escape, we don't need this auto_escape by default, but maybe in some case you would like to, If you don't already have made this job done yourself like say @xPaw |
so your suggestions are:
Yes, this is the best solution. All we need now is a modifier We can add a new modifier autoload functionality, so any time a new modifier is called, if the function doesn't exists, RainTPL will load it from a modifier folder e.g. This should obviously be developed in another pull request, with priority on this, so when that is ready we merge in master and then merge this into master. Sounds like a good plan to me, do you agree? |
{$var|safe}
{$var|safe|substr:5}
Above could skip the auto escape feature.