>
> As far as my table comment, I meant that when I used the SQL table and its
> Fields to create an SQLTABLE, the labels "just worked" and produced a
> column header with the desired symbol instead of printing "≤" in the
> column heading. So SQLTABLE behavior differed from SQLFORM in this manner.
>
Can you show your SQLTABLE code? When I do SQLTABLE(..., headers='labels'),
which uses the field labels to generate the headers, I get the exact same
output as in a SQLFORM (i.e., the values are escaped).
> I have found a workaround, finally, which lets me have symbols in both
> forms and tables:
>
> elapsed_time_field("lcm_gt",label=CAT(T("LCM"),XML(" >"))),
> elapsed_time_field("lcm_le",label=CAT(T("LCM"),XML(" ≤"))),
> elapsed_time_field("scm_gt",label=CAT(T("SCM"),XML(" >"))),
> elapsed_time_field("scm_le",label=CAT(T("SCM"),XML(" ≤"))),
> elapsed_time_field("scy_gt",label=CAT(T("SCY"),XML(" >"))),
> elapsed_time_field("scy_le",label=CAT(T("SCY"),XML(" ≤"))),
>
Why bother with the CAT()? Just do:
label=XML(T("LCM ≤"))
which is your original label simply wrapped in XML().
> I first tried the obvious, letting T() handle the substitution but again,
> that doesn't work. The &xx; character escapes get printed literally in the
> form label instead of creating the symbol I intended. So I got around the
> problem with CAT(). Still, an awful amount of work and hassle to
> reverse-engineer and make a work around for something that just should have
> worked.
>
First, I'm not sure why the complaint. The book clearly states that all
text injected in views is escaped, and this is to protect against XSS
vulnerabilities (as well as for proper HTML parsing and displaying of
special characters intended as page content). The book also clearly states
how you can override the default escaping -- by wrapping the content in
XML(), which works exactly as expected in this case. No need for any
reverse-engineering or workarounds -- just use the documented functionality.
Second, before you vent, keep in mind that the framework, documentation,
and support are all being provided by folks who are volunteering their time
and energy for free.
> I'm not sure why &xx; is "sanitized" to begin with. It seems like an
> extreme form of sanitizing, to eliminate any and all special characters
> from form labels.
>
I think that's fairly standard -- see
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Output_Encoding_Rules_Summary.
Aside from security issues, the escaping also serves to ensure that various
special characters are displayed properly (e.g., converting "&" to "&"
results in the "&" being displayed on the page, which is typically what we
want). Of course there are cases where we don't need/want the escaping, but
the framework cannot know for sure where those cases are, so we err on the
side of better security and leave it up to the developer to explicitly mark
text that should not be escaped.
Anthony
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
