Skip to content
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

Auto-escaping on function and block handlers is underdefined #915

Open
wisskid opened this issue Nov 6, 2023 · 2 comments
Open

Auto-escaping on function and block handlers is underdefined #915

wisskid opened this issue Nov 6, 2023 · 2 comments

Comments

@wisskid
Copy link
Contributor

wisskid commented Nov 6, 2023

function and block handlers should at least somehow indicate what they are returning, i.e. plain text, html, js, etc.
That way, we would be able to apply auto-escaping when needed and refrain from it when not needed.

see #906

This also needs to be documented

@gkreitz
Copy link
Contributor

gkreitz commented Nov 28, 2023

Have you considered adding something like SafeString (shamelessly borrowed from Django, https://docs.djangoproject.com/en/4.2/_modules/django/utils/safestring/ ), a small wrapper class around a string to indicate that the user has taken responsibility for escaping, and that the contained string is safe for output?

That would allow a function to indicate that it has taken care of escaping by returning SafeString, or that its output should be escaped (by returning string).

As an added bonus, the same mechanism would also allow for users to supply escaped HTML in normal template variables. So, {$foo} would render <html> when one has done $smarty->assign('foo', new Smarty\SafeString('<html>')). If one instead did $smarty->assign('foo', '<html>'), it would render &lt;html&gt; (as it currently does).

As a secondary bonus, {capture} in templates could use SafeString (as what is captured will have been escaped), which would get rid of needing to use nofilter when one prints captured content.

@wisskid
Copy link
Contributor Author

wisskid commented Nov 29, 2023

Very interesting idea, @gkreitz !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants