When reading the VTL reference for Velocity 1.7 at the bottom of the doc there was a reference to Unparsed content.
Unparsed content is rendered at runtime, but is not parsed or interpreted.
Example:
#[[
This has invalid syntax that would normally need "poor man's escaping" like:
#define()
${blah
]]#
I'm simply wondering if this is supported in nVelocity but not documented.
It's not implemented. Which means that you get to do it :-)
Create an issue, then fork the repository and implement it, then send the team a pull request.
It is supported. But I guess not the multi-line statement.
For example, this below is supported:
#[[ #define() ${blah ]]#
This is not:
#[[
#define() ${blah
]]#
Related
My use case is simple: I am sending text emails, i am trying to make integrations tests in order to check the full text body of the message, please note I don't want to check if message contain a string, i am looking for format and structure. No fancy check since it is just text.
The current public API, as in documentation, and as I see in code allows me to check only whether the message contains a string assertEmailTextBodyContains().
I did read: https://symfony.com/doc/current/mailer.html#write-a-functional-test, from MailerAssertionsTrait can only get a RawMessage, i tried, but did not get a strait way to wrap it within an Email.
What am I missing?
Is there any technical/non technical issue preventing to have such Constraint implemented?
Something like: assertEmailTextBodySameAs() for example.
Just for the sake of documentation.
After informing my self more, i realise that in my ignorance i was looking for an idiomatic syntax in the MailerAssertionsTrait instead what i needed was just to use the IsIdentical constraint from phpunit.
$this->assertThat($email->getTextBody(), new IsIdentical($expectedText), 'Mail body are not the same');
Why such assertion is not built in in trait i did assume it is just to keep it simple allowing others like me to extend later on easily, it is just an speculation though.
In the documentation for jsonapi for pagination is says the following:
For example, a page-based strategy might use query parameters such as
page[number] and page[size]
How would I represent this in the query string? http://localhost:4200/people?page[number]=1&page[size]=25, I don't think using a map link structure is a valid query string. Only the page parameter is reserved according to the documentation.
I don't think using a map link structure is a valid query string.
You're right technically, and that's why the spec has the note that says:
Note: The example query parameters above use unencoded [ and ] characters simply for readability. In practice, these characters must be percent-encoded, per the requirements in RFC 3986.
So, page[size] is really page%5Bsize%5D which is a valid query parameter name.
Only the page parameter is reserved according to the documentation.
When the spec text says that only page is reserved, it actually means that any page[......] style query parameter is reserved. (I can tell you that for sure as one of the spec's editors.) But it should say so more explicitly, so I'll open an issue for it.
I was reading some questions trying to find a good solution to preventing XSS in user provided URLs(which get turned into a link). I've found one for PHP but I can't seem to find anything for .Net.
To be clear, all I want is a library which will make user-provided text safe(including unicode gotchas?) and make user-provided URLs safe(used in a or img tags)
I noticed that StackOverflow has very good XSS protection, but sadly that part of their Markdown implementation seems to be missing from MarkdownSharp. (and I use MarkdownSharp for a lot of my content)
Microsoft has the Anti-Cross Site Scripting Library; you could start by taking a look at it and determining if it fits your needs. They also have some guidance on how to avoid XSS attacks that you could follow if you determine the tool they offer is not really what you need.
There's a few things to consider here. Firstly, you've got ASP.NET Request Validation which will catch many of the common XSS patterns. Don't rely exclusively on this, but it's a nice little value add.
Next up you want to validate the input against a white-list and in this case, your white-list is all about conforming to the expected structure of a URL. Try using Uri.IsWellFormedUriString for compliance against RFC 2396 and RFC 273:
var sourceUri = UriTextBox.Text;
if (!Uri.IsWellFormedUriString(sourceUri, UriKind.Absolute))
{
// Not a valid URI - bail out here
}
AntiXSS has Encoder.UrlEncode which is great for encoding string to be appended to a URL, i.e. in a query string. Problem is that you want to take the original string and not escape characters such as the forward slashes otherwise http://troyhunt.com ends up as http%3a%2f%2ftroyhunt.com and you've got a problem.
As the context you're encoding for is an HTML attribute (it's the "href" attribute you're setting), you want to use Encoder.HtmlAttributeEncode:
MyHyperlink.NavigateUrl = Encoder.HtmlAttributeEncode(sourceUri);
What this means is that a string like http://troyhunt.com/<script> will get escaped to http://troyhunt.com/<script> - but of course Request Validation would catch that one first anyway.
Also take a look at the OWASP Top 10 Unvalidated Redirects and Forwards.
i think you can do it yourself by creating an array of the charecters and another array with the code,
if you found characters from the array replace it with the code, this will help you ! [but definitely not 100%]
character array
<
>
...
Code Array
& lt;
& gt;
...
I rely on HtmlSanitizer. It is a .NET library for cleaning HTML fragments and documents from constructs that can lead to XSS attacks.
It uses AngleSharp to parse, manipulate, and render HTML and CSS.
Because HtmlSanitizer is based on a robust HTML parser it can also shield you from deliberate or accidental
"tag poisoning" where invalid HTML in one fragment can corrupt the whole document leading to broken layout or style.
Usage:
var sanitizer = new HtmlSanitizer();
var html = #"<script>alert('xss')</script><div onload=""alert('xss')"""
+ #"style=""background-color: test"">Test<img src=""test.gif"""
+ #"style=""background-image: url(javascript:alert('xss')); margin: 10px""></div>";
var sanitized = sanitizer.Sanitize(html, "http://www.example.com");
Assert.That(sanitized, Is.EqualTo(#"<div style=""background-color: test"">"
+ #"Test<img style=""margin: 10px"" src=""http://www.example.com/test.gif""></div>"));
There's an online demo, plus there's also a .NET Fiddle you can play with.
(copy/paste from their readme)
I want to make an XML document from an HTML one so I can use the XML parsing tools. My problem is that my HTML is not guaranteed to be XHTML nor valid. How can I bypass the exceptions? In this string <p> is not terminated, nor is <br> nor <meta>.
var poorHtml:String = "<html><meta content=\"stuff\" name=\"description\"><p>Hello<br></html>";
var html:XML = new XML(poorHtml);
TypeError: Error #1085: The element type "meta" must be terminated by the matching end-tag "</meta>".
I did some searching and couldn't come up with anything except this doesn't really seem possible, the major issue is how should it correct when the format is not valid.
In the case of browsers, every browser does this based upon it's own rules of what should happen in the case that the closing tag isn't found (put it in wherever it would cause the code to produce a valid XML and subsequently DOM tree, or self terminate the tag, or remove the tag, or for the case that a closing tag was found with no opening how should this be handled, what about unclosed attributes etc.).
Unfortunately I don't know of anything in the specification that explains what should be done in this case, with XHTML just like how flex treats it these are fatal errors and result in no functionality rather than how HTML4 treated it with the quirky and transitional DTD options.
To avoid the error or give better error messaging you can use this:
var poorHtml:String = "<html><meta content=\"stuff\" name=\"description\"><p>Hello<br></html>";
try
{
var html:XML = new XML(poorHtml);
}
catch(e:TypeError)
{
trace("error caught")
}
but it's likely you'll be best off using some sort of server side script to validate the XML or correct the XML before passing it over to the client.
There is probably an implementation of HTML Tidy in just about any language you might happen to be working with. This looks promising for your sitation: http://code.google.com/p/as3htmltidylib/
If you don't want to drag in a whole library (I wouldn't), you could just write your own XML parser that handles errors in whatever way suits you (I'd suggest auto-closing tags until the document makes sense again, ignoring end tags with no start tags, maybe un-closing certain special tags such as "body" and "html"). This has the added advantage that you can optimize it for whatever jobs you need it for, i.e. by storing a list of all elements with the attribute "href" as you come to them.
You could try to pass your HTML through HTML Tidy on the server before loading it. I believe that HTML Tidy does a good job at cleaning up broken HTML.
The closest thing I could find was System.Net.Mime.MediaTypeNames but that doesn't seem to have everything (like json) since it seems to be more focused around email attachments.
An enum doesn't make much sense. MIME types are open-ended. That is, the list is not finite: new types are added from time to time.
See RFC4288: Media Type Specifications and Registration Procedures
In 2022, with .NET Core and .NET5+, this is now available via MediaTypeNames. For example:
MediaTypeNames.Application.Json
MediaTypeNames.Image.Png
MediaTypeNames.Text.Html
Microsoft documentation around MediaTypeNames, and each of Application, Image, Text.
https://learn.microsoft.com/en-us/dotnet/api/system.net.mime.mediatypenames?view=net-6.0
https://learn.microsoft.com/en-us/dotnet/api/system.net.mime.mediatypenames.application?view=net-6.0
https://learn.microsoft.com/en-us/dotnet/api/system.net.mime.mediatypenames.image?view=net-6.0
https://learn.microsoft.com/en-us/dotnet/api/system.net.mime.mediatypenames?view=net-6.0
https://learn.microsoft.com/en-us/dotnet/api/system.net.mime.mediatypenames.text?view=net-6.0
IANA's database is most likely to be complete. Currently, they have the list available in CSV format at https://www.iana.org/assignments/media-types/application.csv. I am assuming this is a stable URL whose content changes as updates are made. If you want to stay up to date, you'd need to put together a mechanism that is appropriate for your needs.
There is also the mime.types file that comes with Apache which seems to have been derived from the said list.
If like me you wanted to have no hard-coded string in your code you can use something like below
httpHeaders.add(HttpHeaders.CONTENT_TYPE,MediaType.APPLICATION_JSON_VALUE);
which is essentially
httpHeaders.add("Content-Type","application/json");