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

Allow HTML in title_resolved (to allow font-awesome icons) #305

Open
PetrDlouhy opened this issue Aug 6, 2021 · 4 comments
Open

Allow HTML in title_resolved (to allow font-awesome icons) #305

PetrDlouhy opened this issue Aug 6, 2021 · 4 comments

Comments

@PetrDlouhy
Copy link
Contributor

There is 1 thing, for which I have to override the whole template. I am using font-awesome icons, so I need to make the item.title_resolved safe (see #91 (comment)). I don't think, that is wise to add something like that to templates generally (in some systems users could have access to the sitetree editing). But I can either do something like

{% block title %}{{ item.title_resolved }}{% endblock %}

so that only this part of the template needs to be overriden, or it can be done by some settings (like SITETREE_FORCE_SAFE=True).
What do you think is better?

This has been already discussed at #304 and #91 (comment)

@PetrDlouhy
Copy link
Contributor Author

@idlesign The mark_safe() should do the same think, as |safe filter. Except we can better handle it in the code.
But the main issue still remains - how we avoid exploiting HTML implementation, if the implementors give users access to sitetree edition.

The suggested method with annotating templates with blocks is most general - it could be useful in more cases, if users could override smaller sections of the template, not just the whole template.

I also taught about third option - sanitize the HTML with html-sanitizer or something similar. It is easiest to use, but would introduce additional dependency.

@idlesign
Copy link
Owner

idlesign commented Aug 6, 2021

The mark_safe() should do the same think, as |safe filter. Except we can better handle it in the code.

Yeap, it's single entry point (code edit) versus multiple (override n templates).

The suggested method with annotating templates with blocks is most general - [...]

Blocks are fine, except we'll need to define them carefully to cover top user cases.
To be thought of:

  1. What about block nesting?
  2. Where to get those top user cases from?

sanitize the HTML with html-sanitizer or something similar.

That'll cost us not only a dependency but also a performance hit.

@PetrDlouhy
Copy link
Contributor Author

OK, so do you agree that the best method would be to use mark_safe() when allowed by some settings variable?

The templates annotation can be left to different issue - I think, it we can find some logical parts and that the blocks can be nested (users can choose which level they will override).

@idlesign
Copy link
Owner

idlesign commented Aug 6, 2021

OK, so do you agree that the best method would be to use mark_safe() when allowed by some settings variable?

What I'm concerned with is: if it'd be a global settings marking all sitetrees' templates tags output safe it might become an excellent for XSS, depending on who'd have an access to menu items edit.

For many years sitetree has been conservative on subject of adding new fields etc. but giving sane means of customization.
And I'd rather stick to the strategy.

So if we're able to come up with a solution covering a common case, it'd be fine. But if it's a one or two projects need it won't worth additional complexity.

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