Mostly able to because Guile's web server is standard, and if you need to bypass the framework, you can rather easily.
It's more than fast enough for most people's needs. Flexible, because Scheme, and Artanis' design will be familiar to all the Flask/etc devs.
I do not know, whether GNU Artanis makes use of SXML all the way, but I think it is very likely, since SXML is in GNU Guile's standard library.
(All the other nodes are symbols with potentially subtrees in them, which are also symbols with potentially more subtress in them.)
If you put your user input into one such node as a value of that node, lets say a paragraph tag <p>, then SXML sees the user input as it is, a string. It will make sure, that when it turns the tree into HTML, that string remains merely a string, by escaping things, so that for example when your string is <evil-tag-with attrs="bla"> this is exactly what will be seen as text inside your paragraph text, and not be interpreted.
Basically, SXML will render it like: "Oh, you want some string to be inside your p tag? Sure, can do ... This is what you wanted to be displayed to the user ... You didn't want to run that, did you? Nahh, because then you wouldn't have passed it in the SXML as text content of a p tag."
So I think the answer to your question is "Yes.".
But of course this only applies when you use sxml. Artanis apparently can also use plain strings or templates as responses, in which case you will have to take care of safely encoding things too.
Rather, things are structured, so it's more like a in-memory representation of XML. It doesn't need to be serialised, only deserialised into XML's text syntax. In which case, each piece knows how it needs to be encoded.
'(h1 (@ (id "greeting")) "Hi, there")
<script>alert("yoov bin acked")</script>
So I was wondering if this framework auto-HTML-escapes strings inserted into places where text can go.
CSRF is cross site request forgery, f.ex. creating a POST form on a hostile site that targets a POST processing endpoint in on site with data that the user didn't want to supply, but whose login cookie would authorize the request at the target.
Many frameworks inject an per-user "authentication" cookie in form's that is validated upon request, this way an attacker cannot trick the users browser to submit data since they don't have the correct CSRF-cookie.
https://owasp.org/www-community/attacks/csrf
https://developer.mozilla.org/en-US/docs/Web/Security/Attack...
But, specifying your own headers is easy, and we had it in a macro we used for our routes.
So instead, to rip from the manual:
(response-emit
body
#:status 200
#:headers '(
(Content-Type . application/json)
(X-Frame-Options . DENY)
)
#:mtime (current-time))Many frameworks inject an per-user "authentication" cookie in form's that is validated upon request, this way an attacker cannot trick the users browser to submit data since they don't have the correct cookie.
https://owasp.org/www-community/attacks/csrf
https://developer.mozilla.org/en-US/docs/Web/Security/Attack...
And the standard ways of doing that, generating single use tokens, will work the way they usually do.
As I said... I didn't use cookies. Which means none of what you listed applied in the first place. Logins were entirely ephemeral and died after a single session ended - as pains were taken to ensure anonymity.
About Artanis itself... It looks really cool! Scheme is such a nice language to code and hack with; but, how safe would it be to expose it directly?
I see they are dogfooding on the Guix packages website, so... I'm guessing it's pretty well tested.
If you have really good Scheme programmers, who know their system, and built it competently, it's probably safer to expose that than your average conventional system.
(Example: A system in Scheme was the first to get a particular certification for sensitive data hosting on cloud servers. Partly because the very small team that developed it knew the stack inside and out, and could do whatever needed to be done, in a smart way.)
(Meanwhile, say, a consulting firm-led team who got a contract for a comparably complex system, and billed for 10 or 100 times the seat-warmers, with huge and ridiculously complex stacks they didn't understand... would just flounder, focus on appearances in sprint tasks, and churn out things implemented in poor ways, and with a large number of vulnerabilities, and probably take a lot longer before they could deliver a system that would survive the first day of use.)
What system was this?
I have particular personal experience with an app that could be done within several months with handful of people but was developed over several years by team of 50. I was flabbergasted at first but you need to understand politics first.
- Irrelevant noise at the beginning of the landing page.
- "What is it" is under the FAQ section, which has a heading that is the same size as the parent heading.
- It consumes all horizontal space.
That's a great thing. Sites which restrict text to a narrow column are a horrible reading experience. I have a large monitor and I wish to use a large monitor!
- At least there are no images of fake people
- It's in an <h1> on top of the page
- `max-width: 60em` is absolutely reasonable
It's a weird time for art. A lot of people's immediate reaction to genuine expression these days is "cringe".
I suppose that's always been the case to some degree, but it feels more prevalent now with internet-level attention span and broadcasting breadth.
That is no country for old men. The young
In one another's arms, birds in the trees,
—Those dying generations—at their song
As another commenter pointed out, the poem is a parody of a Yeats poem. An an extract from another of his poems might offer some insight into the reactions...
What need you, being come to sense,
But fumble in a greasy till
And add the halfpence to the pence
And prayer to shivering prayer, until
You have dried the marrow from the bone
If you're defining a Web server route handler, it's reasonable to do it as you would in most languages, like this package's example:
(get "/hello/:who"
(lambda (rc)
(format #f "<p>hello ~a</p> " (params rc "who"))))
(define-http-get-route ("/hello/" who)
(format #f "<p>hello ~a</p> " who))
(define (hello-world-handler request request-body)
(values '((content-type . (text/plain)))
"Hello World!"))It doesn't implement what many Web "backend" developers now call "routing", which means the programmer specifying a rule-based mapping of URL patterns to a set of handlers for different kinds of requests using a simple DSL, and then at run time the library/framework performing the parsing and dispatch based on those rules.
With that stock Guile library only, I think you'd instead have to manually parse the `request` argument, like in this example:
https://www.gnu.org/software/guile/manual/html_node/Web-Exam...
(define-http-get-route ("/hello/:who")
(format #f "<p>hello ~a</p> " who))Sometimes it makes sense (e.g., if you want to support chunks of hairy SQL pasted into the code).
I could go either way on how to specify Web server routes, but decided to go with the way I did, for 3 reasons:
1. Looks more familiar to Scheme programmers, without bindings coming out of strings (which I don't think is idiomatic Scheme).
2. Can be implemented more portably, including in Schemes that have only `syntax-rules` as a transformer.
3. If more semantics are added to the route specification later, such as type or validation, you might want want to be doing it in s-expressions rather than in a string.
(define-http-get-route ("/hello/:who" who)
(format #f "<p>hello ~a</p> " who))
The reason I switched was that I wanted to use my small programs on servers, and with Chicken Scheme it was easy to build a statically linked executable. Guile should definitely be packageable as such, if someone versed in C has the patience, but it isn't out of the box and there are no "project templates" out there.
Sorry for the plug, but I wrote a Racket book last year and I am just now about 20% of the way through a Gerbil Scheme book. I have a luxury: I am retired so I can write on topics that fascinate me, even if I get small audiences.
Very little visibility as well, Scheme is already a niche. By catering to only the most FOSS oriented/adamant part of the public, your pool of devs is very tiny.
Most guile libs can also only be installed through Guix or failing that, tar files.
The ergonomics of the language are bad and there no concerted community story and publicity around it either imo.
It's sad because it's a cool language and the efforts Wingo and people like the Spritely institute have put into it, are amazing.
Compared to some other languages, the ecosystem is small though. While in Python often you have 3 or 4 libraries solving the same or similar problem, in GNU Guile you often only have 1 or need to write your own. Knowledgeable people are able to quickly throw something together, or call out to C libraries using FFI, but I have not done FFI yet. Some day I really should look into that ... And into Hoot by Spritely Institute [1]
If one wants to check out more algorithmic stuff, I also have some stuff on that: AoC 2024[2] (and previous years too), and guile-algorithms[3] (not that much yet, but useful things, and trying to keep it fully functional). Some time ago I also wrote a toy implementation of a decision tree in Guile[4]. It is even parallelized and achieves linear speedup in my tests. I call it a toy, because you will have to do all the data preparation yourself, because it only deals with numbers, and there are probably smarter ways of storing the data for each node, maybe even avoiding duplication. There is also no library like numpy or dataframes like in Python, so I am using possibly not so optimal data structures. But it is probably worth checking out and adapting, if anyone wants to make a proper decision tree library. It is a start.
[1]: https://spritely.institute/ [2]: https://codeberg.org/ZelphirKaltstahl/advent-of-code-2024 [3]: https://codeberg.org/ZelphirKaltstahl/guile-algorithms [4]: https://codeberg.org/ZelphirKaltstahl/guile-ml
The greatest barrier I had with it was the installation.
The LSP is the biggest missing piece for these niche languages.
In my perspective the reason why it still hasn't taken over is because it's not a focused and supported effort. In my understanding Guile should have been "the GNU scripting language" but the integration is nowhere near what a universal language would be (GNU Make integration is disappointing and totally not what I was expecting).
Then the fact that the project seems to be hopping between different directions (last time I checked they wanted to be a runtime for more than one language).
And they also lived their own Python2 -> Python 3 "migration pain". (In my above gist, I specifically had to compile Guile from source because at that time some application with a hard dependency on Guile2 wasn't getting updated in Fedora, which was holding back the Guile v3 rollout).
aaron_m04•5mo ago
em-bee•5mo ago
eisvogel•5mo ago
g8oz•5mo ago