Show HN: Rocket – Web Framework for Rust • Hacker News Board

Re: Show HN: Rocket – Web Framework for Rust

#121

Post by aban » Mon, Dec 26, 2016, 2:21 PM UTC

iopq wrote: post #119

paulddraper wrote: post #118

Earlier quoted context omitted.

I don't see why javascript: is fundamentally different than other XSS vectors

because for other types of injections Yesod WILL actually properly encode tags and make them <script> which will prevent SOME XSS exploits but it doesn't prevent all of them

This is not true, at least not anymore.

Yesod uses xss-sanitize [0], and their sanitize function does indeed prevent "javascript:" attempts. They even have a test case for it [1].

Playing around with it in the REPL:

  Prelude Text.HTML.SanitizeXSS Data.Text> sanitize $ pack ""
  ""
  Prelude Text.HTML.SanitizeXSS Data.Text> sanitize $ pack ""
  ""
  Prelude Text.HTML.SanitizeXSS Data.Text> sanitize $ pack ""
  ""
  Prelude Text.HTML.SanitizeXSS Data.Text> sanitize $ pack ""
  ""

[0]: https://hackage.haskell.org/package/xss-sanitize

[1]: https://github.com/yesodweb/haskell-xss-sanitize/blob/9a9101...

Re: Show HN: Rocket – Web Framework for Rust

#122

Post by chias » Mon, Dec 26, 2016, 8:27 PM UTC

Being very excited about another Rust web framework, I've been trying to use this for the last few days. While the basics seem very interesting, there's a few large stumbling blocks ready for anyone who might want to "get serious" with it.

Documentation is very sparse. Indeed, the linked to page seems to be the primary documentation repository. This is particularly painful for a brand new project, because googling is wholly useless at this point (the only relevant results being the linked-to page). You can try to infer things from the API, but there's a lot that I would refer to as "hidden gotchas" which you'll only learn about through experimentation or by reading the source.

For example, consider the FromForm functionality. Does it decode url-encoded values? Turns out the answer is: maybe. If your struct defines the field as a String then the input will be url-decoded, but if you define the field as a str then it won't be. FromForm only works at all if the submission is of content-type 'application/x-www-form-urlencoded', failing entirely 'multipart/form-data' for example -- I have no idea how you're meant to go about parsing a multipart form besides doing it manually using just the raw post-data string as input. Also, good luck parsing anything with a checkbox (as their code example does) -- if the checkbox is checked, no problem, the field is populated with 'true'. But if the checkbox is left unchecked, then you get a parse failure because you're "missing" a field. There may be a way to work around this but if there is it isn't well documented and I haven't read through that part of the rocket source yet.

Re: Show HN: Rocket – Web Framework for Rust

#123

Post by strictfp » Fri, Dec 30, 2016, 4:58 PM UTC

oxymoron wrote: post #75

strictfp wrote: post #64

Earlier quoted context omitted.

Ok, I hear you. I agree somewhat, but not totally :) To me, the most important aspect of programming is to retain full control. I for instance want to be able to register my HTTP endpoints based on some data read from a file. I want to be able to start my app in server mode and run requests against it in any way I want during testing. What many of these frameworks do is to remove this power. Bytecode modification is…

To jump into a really interesting discussion: I totally get what the both of you are saying, but I think that the real problem are poor abstractions. In some sense SQL is code generation since it's a declarative way of describing what you want which the query planner figures out how to realize. At least to me, it's rarely a source of frustration. Why? Because it's a sound, proven abstraction based on a very solid fou…

I had to think about your comment. Yes, SQL is a sort of code generation and you could argue that annotating classes also is code generation. But my main pain point is that most annotation frameworks are frameworks and assume that they are in control: that they start the app and that the application programmer must write their whole app according to the rules of the framework. That's like if a SQL client lib would assume that the whole app was written in SQL.