The nice thing about Python is if you just target the WSGI spec, you can have a web framework that can be deployed to an insane amount of web servers. It's just a standard for how you receive incoming requests and what have you, other languages have similar offerings. So yes, Spider could be a thing in a few weeks. I forget if Bottle.py is WSGI based or not, but it wouldnt surprise me if you could conjure up something as small as Bottler.py that specifically works with WSGI.
Edit: Sitting down and writing my own WSGI web library is on my bucket list, I just have other items I want to do more.
I don’t use it anymore though. By the time I finished writing it, I was already hooked to Common Lisp and Hunchentoot for web development. So this tiny WSGI microframework remained as a hobby project.
I'm still hooked to Python though I get paid for .NET and so I think it would do me good to build a WSGI web library so I feel more confidence working with WSGI, of course most web libraries implement it well enough I never notice or care that WSGI is being used outside of configuring it and moving on, Django is a good example of this.
What if data['time'] is '<script>alert("oops!")</script>'?
While JavaScript's template literals [1] would allow this kind of API to work (because the prefix of the template string can be a function that escapes the parameters), Python's f-strings doesn't have equivalent functionality. The tuple returned from the render function should probably include an additional item containing the parameters for the format string (which shouldn't be an f-string).
The second example from the documentation [1] disagrees. It displays HTTP header values, which are user supplied, without properly encoding them.
Also, it's not just about JavaScript. If values aren't properly encoded as HTML, the app is just plain broken when it tries to display text that contains certain character sequences. For example, the app is not capable of displaying the data value "To create a heading in HTML, use <h1>My heading</h1>".
The values need to be separated from the format string and passed through an encoding function such as html.escape [2]. Django learned this lesson 15 years ago in version 1.0 [3].
Sure, you're right about that and I agree with the specifics, but your message doesn't feel relevant to the OP or the discussion.
Is it a reasonable expectation that every dev and blog posts must rehash all of OWASP and audit their experimental frameworks (now several years in the making) before publishing?
19 comments
[ 4.1 ms ] story [ 23.5 ms ] threadEdit: Sitting down and writing my own WSGI web library is on my bucket list, I just have other items I want to do more.
I did something like that many years ago: https://github.com/susam/ice
Documentation: https://icepy.readthedocs.io/en/latest/tutorial.html
I don’t use it anymore though. By the time I finished writing it, I was already hooked to Common Lisp and Hunchentoot for web development. So this tiny WSGI microframework remained as a hobby project.
https://peps.python.org/pep-0498/
Just was curious if anyone solved this DX issue in a more elegant way.
While JavaScript's template literals [1] would allow this kind of API to work (because the prefix of the template string can be a function that escapes the parameters), Python's f-strings doesn't have equivalent functionality. The tuple returned from the render function should probably include an additional item containing the parameters for the format string (which shouldn't be an f-string).
See also [2].
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[2] https://en.wikipedia.org/wiki/Uncontrolled_format_string
Also, it's not just about JavaScript. If values aren't properly encoded as HTML, the app is just plain broken when it tries to display text that contains certain character sequences. For example, the app is not capable of displaying the data value "To create a heading in HTML, use <h1>My heading</h1>".
The values need to be separated from the format string and passed through an encoding function such as html.escape [2]. Django learned this lesson 15 years ago in version 1.0 [3].
[1] https://github.com/healeycodes/jar#fresh-pages
[2] https://docs.python.org/3/library/html.html#html.escape
[3] https://docs.djangoproject.com/en/3.2/releases/1.0-porting-g...
Is it a reasonable expectation that every dev and blog posts must rehash all of OWASP and audit their experimental frameworks (now several years in the making) before publishing?