Commit message (Collapse) | Author | Files | Lines | ||
---|---|---|---|---|---|
2022-01-06 | Add `#![deny(unreachable_pub)]` to all crates | 1 | -0/+1 | ||
2022-01-06 | Omit implicit lifetimes | 1 | -2/+2 | ||
2022-01-06 | Add `#[derive(Debug)]` for public types | 1 | -0/+3 | ||
2021-12-22 | Fix suggestions from nightly clippy | 1 | -0/+1 | ||
2021-07-01 | Stop eliding lifetimes in paths | 1 | -0/+1 | ||
2021-05-17 | Remove forward-slash escape (#486) | 1 | -1/+0 | ||
This was based off of the OWASP XSS prevention cheat sheet -- https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#output-encoding-rules-summary However, there isn't really any attack vector based on forward slash alone, and it's being removed in the next version of that document. > There is no proof that escaping forward slash will improve > defense against XSS, if all other special characters are escaped > properly, but it forces developers to use non-standard implementation of > the HTML escaping, what increases the risk of the mistake and makes the > implementation harder. https://github.com/OWASP/CheatSheetSeries/pull/516 | |||||
2021-01-15 | Add no_std support to askama_escape | 1 | -3/+10 | ||
2020-05-24 | Update `EscapeWriter` HTML implementation to not output empty strings | 1 | -1/+5 | ||
2019-07-25 | Update formatting | 1 | -4/+1 | ||
2019-06-14 | Change askama_escape to require UTF-8 strings | 1 | -24/+25 | ||
2019-01-12 | Specify a trait that handles the output format's escaping | 1 | -55/+108 | ||
2019-01-12 | Slightly simplify escaping code | 1 | -19/+21 | ||
2019-01-06 | Improved rendering time (#190) | 1 | -1/+23 | ||
* Improved rendering time * Fix useless codes | |||||
2018-12-08 | Use 2018 edition idioms | 1 | -3/+3 | ||
2018-11-07 | Create askama_escape crate | 1 | -0/+100 | ||