phutil_escape_html can handle these objects, but pht needs to know to call it.
Details
- Reviewers
epriestley - Group Reviewers
Blessed Reviewers - Commits
- rPHU32c56dc20b39: let pht expect PhutilSafeHTMLProducerInterface
Render a couple of things? I'm not sure how much damage this can do.
Diff Detail
- Repository
- rPHU libphutil
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
You've mentioned we might need this in D16236, and my quick test worked, but that was because I also had a renderAuthor() in my test input, which triggered the "this is html" flag.
Alternatively, I can just add another ->render() in D16236, which is there in the existing Transaction's renderHandle() (User's renderHandle() doesn't "render" HTML, but produces a PHUIView).
Or maybe just pretend everything is HTML in this function, so we escape all inputs?
We should possibly make PhutilSafeHTML implement PhutilSafeHTMLProducerInterface (just as return $this;, I think) to simplify this and a couple of other checks, but that's just a tiny implementation detail.
Calling render() means we have to load the handle immediately, so that's not desirable.
I believe escaping only when necessary is a (possibly significant?) optimization.
The data access pattern here is probably still not great -- I think pht(..., $this->renderHandle()) will end up loading the handle before pht() returns. But that's fixable (by making pht() return an object which evaluates lazily, at least some of the time) as long as we don't call render() inline.