| Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Updates the requirements on [comrak](https://github.com/kivikakk/comrak) to permit the latest version.
- [Release notes](https://github.com/kivikakk/comrak/releases)
- [Changelog](https://github.com/kivikakk/comrak/blob/main/changelog.txt)
- [Commits](https://github.com/kivikakk/comrak/compare/0.12.0...0.13.0)
---
updated-dependencies:
- dependency-name: comrak
dependency-type: direct:production
...
Signed-off-by: dependabot[bot] <support@github.com>
|
|
Just migrated a repo from tera to askama and this was one of the only
things that was different. This is also coherent with `{% block %}` for
which I added the same feature years ago.
|
|
|
|
"suppress" and "preserve"
|
|
|
|
Previously the built-in json filter had an issue that made it unsafe to
use in HTML data. When used in HTML attributes an attacker who is able
to supply an arbitrary string that should be JSON encoded could close
the containing HTML element e.g. with `"</div>"`, and write arbitrary
HTML code afterwards as long as they use apostrophes instead of
quotation marks. The programmer could make this use case safe by
explicitly escaping the JSON result: `{{data|json|escape}}`.
In a `<script>` context the json filter was not usable at all, because
in scripts HTML escaped entities are not parsed outside of XHTML
documents. Without using the safe filter an attacker could close the
current script using `"</script>"`.
This PR fixes the problem by always escaping less-than, greater-than,
ampersand, and apostrophe characters using their JSON unicode escape
sequence `\u00xx`. Unless the programmer explicitly uses the safe
filter, quotation marks are HTML encoded as `"`. In scripts the
programmer should use the safe filter, otherwise not.
|
|
|
|
Sometimes for no obvious reason an old version is selected and the
output is different in just about every ui test. Just pin it to the
currently newest version and test if an updated version still works when
a new version gets released.
|
|
|
|
|
|
|
|
Askama understands how to destructure tuples in let and match
statements, but it does not understand how to build a tuple.
This PR fixes this shortcoming.
|
|
This change allows using the operator `?` in askama expressions. It
works like the same operator in Rust: if a `Result` is `Ok`, it is
unwrapped. If it is an error, then the `render()` method fails with this
error value.
|
|
Instead of having `Expr::VarCall`, `Expr::PathCall` and
`Expr::MethodCall`, this PR unifies the handling of calls by removing
the former three variants, and introducing `Expr::Call`.
|
|
|
|
This is relatively major change to the main trait's API. For context,
I always started from the concept of monomorphized traits, but later
several contributors asked about object safety. At that point I made
`Template` object-safe, and then even later added a `SizedTemplate`
to make some things easier for people who don't need object safety.
However, having object-safety in the primary trait is bad for
performance (a substantial number of calls into the virtual `Write`
trait is relatively slow), and I don't think those who don't need
object safety should pay for the cost of having it.
Additionally, I feel using associated consts for the extension and
size hint is more idiomatic than having accessor methods. I don't
know why I didn't use these from the start -- maybe associated
consts didn't exist yet, or I didn't yet know how/when to use them.
Askama is pretty old at this point...
|
|
|
|
|
|
|
|
|
|
|
|
This PR implements for-else statements like in Jinja. They make it easy
to print an alternative message if the loop iterator was empty. E.g.
```rs
{% for result in result %}
<li>{{ result }}</li>
{% else %}
<li><em>no results</em></li>
{% endfor %}
```
|
|
|
|
|
|
|
|
|
|
This PR adds `{% break %}` and `{% continue %}` statements to break out
of a loop, or continue with the next element of the iterator.
|
|
|
|
|
|
This PR adds the tests by @msrd0 <git@msrd0.de> that failed before.
The error was fixed somewhen between f23162a and now, so these tests
serve to prevent regressions in the future.
I simplified the tests very slightly to omit whitespaces in the output.
|
|
|
|
`target()` as used in parsing "let" and "if let" implements parsing
nested tuples and structs. But it does not implement parsing literals.
The functions `match_variant()` and `with_parameters()` as used in
parsing "when" blocks do not implement parsing nested structs, but it
implements parsing literals.
This PR combines `match_variant()` and `with_parameters()` into
`target()`, so that all `{%when%}` support nested structs, too.
|
|
Askama uses the syntax `{% when Variant with (parameters) %}` in
`{% match %}` blocks. This is done because Askama does not implement the
whole pattern matching of Rust's `match` statements.
This PR wants to bring Askama a step closer Rust's matching, so the
"with" keyword should not be needed anymore.
|
|
Askama uses the syntax `{% when Variant with (parameters) %}` in
`{% match %}` blocks.
This change allows the optional use of the keyword "with" in "let" and
"if let" statements, too.
|
|
This PR implements the destructoring of structs on the lhs of "let" and
"for" statements.
|
|
|
|
|
|
|
|
The current rust_test uses `stringify!()`. The documentation gives us
the warning:
> Note that the expanded results of the input tokens may change in the
> future. You should be careful if you rely on the output.
In the current nightly rust the result was indeed changed, so the test
not fails.
This PR replaces the test with another macro, that does not depend on
`stringify!()`.
Closes issue #504.
|
|
rust-lang/rust#82069 made error message that stem macro invocations more
verbose. Since Rust 1.54 (currently in beta) the message includes the
name of the offending macro.
This PR uses version_check to select the appropriate expected error
message.
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
René Kijewski
dependabot[bot]
Bastien Orivel
Guillaume Gomez
René Kijewski
Dirkjan Ochtman
vallentin
Kelly Thomas Kline
Restioson
Ryan Kelly
Alex Wennerberg