userserv

Arrgh, now I get to live with the shame of someone looking at my code. Be wary of the https://github.com/Lerc/userserv component, because that's the bit that is only really proof-of-concept level and runs as root. It's the bit that allows user login (it forks and drops privileges to the user before serving static files) It's probably a candidate for a Rust rewrite. I agree on the AI part. When ChatGPT4 came out my test case for it was getting it to make a filesystem on top of IndexDB and and a set of edge case tests. It did quite a respectable job (until it got bigger than the context anyway). I should go back and finish the job now that contexts are larger.

https://github.com/Lerc/userserv/blob/master/authenticationt... This looks like something right out of a CTF. I'm pretty sure you can overflow that buffer and smash the stack. It's also vulnerable to a path traversal attack. What happens if the filename is '../../../etc/passwd'? You should also pass -fstack-protector in your Makefile.

There's a version of some vintage at https://github.com/Lerc/userserv (it's terrible, don't judge me) It has node bits there but they aren't necessary for the basic static serving. If it gets a WebSocket connection it punts it on to node.

I used this a while ago on my own insane project. I had a Webdav server and websocketd providing a Web interface to a Linux box. Even at it's young age (bug reports #5 and #7 were mine), it allowed me to progress a lot further in my project before I needed to write a server designed specifically for the task at hand. In the end I wrote userserv https://github.com/Lerc/userserv for the one must have feature I needed. I needed logins and responses delivered from a process with the UID of the CookieToken. So, thanks Joe. Notanos got further because of websocketd and while I'm not currently using it, There's a high chance of me doing so in future projects.

Speaking from the perspective of someone who touched WebDav and then wrote my own server alternative. WebDav is really that bad. It has a special combination of using XML to be theoretically extensible while generalised to use the lowest common denominator of features. I can't recall the specific details, but I certainly remember the pain. Apart from the inevitable and unnecessary translation from XML to a JavaScript object. I seem to recall there were weird cases where the XML format produced a different structure for cases where directories contained a single file. In the short term I found capturing the output of "ls -al urlpath" was vastly easier to deal with. In the longer term I wrote a server https://github.com/Lerc/userserv It might be worth me revisiting userserv to switch to the SpockFS protocol. Currently I use a websoc

I had a play around in this area a few years ago. I had a tiny index.html that had just this script in the body. var s=localStorage["bootstrap"]; if (s) {eval(s);} else { var t="But you are not carrying the axe!<br>"; t+='<a href="loadup.html">Get the Axe</a>'; document.body.innerHTML=t; } http://fingswotidun.com/notanos/ Ultimately I found that I needed a server side because of URLs and the same-origin policy. There were just some things that browsers expected to fetch from a URL rather than have the data arrive by other means. For a time I used a WebDav server to be a dumb server. Eventually the system evolved into https://github.com/Lerc/notanos Which uses it's own custom server https://github.com/Lerc/userserv which uses your unix login and statically serves files that your logged-in user is allowed to see.