4 ms·

I'm Hales, the author of Minisleep. I'm open to any and all questions, critique and tangential stories. I made Minisleep to solve the problems I had with othe

• mro_name 4y ago
  Have you thought of somehow mitigating brute force auth attacks?
  • krageon 4y ago
    You can mitigate it by having a very long password :)
    • mro_name 4y ago
      lol, indeed. However I would prefer something with less load impact than bcrypt hashing. Or is that yak shaving?
    • hales 4y ago
      We need graphs of "minimum password length" versus "number of CPUs in your shared hosting" :D
  • hales 4y ago
    Yes. Normally I hate passing the buck like this, but this is something you need to configure in your HTTP server (not Minisleep). Minisleep does not handle auth itself, instead HTTP_AUTHENTICATION is handled by your HTTP webserver. Minisleep's scripts do not even get run until authentication succeeds, so they have no way of noticing brute force attacks. I did have code once where minisleep itself handled auth checks (instead of your HTTP server), but I realised this was probably making things worse. You would have to trust my auth checking code AND my rate limiting code AND it would be easier to DDOS. My rate limiting was also a bit naive, blacklisting by IP, which probably isn't enough when facing modern IPv4 botnets or IPv6 in general. My personal website (https://halestrom.net/ https://halestrom.net/) has a commenting system which does do some simplistic rate-limiting in CGI scripts. It's a bit easier there, because one of the rate limits is site-wide, and there is no auth to check, so I'm a lot more comfortable with it. Thankyou for bringing this up, I need to add some docs about server ratelimiting configs (and add them to the pre-made example server configs I ship with Minisleep). I'm so used to using ridiculously complicated passwords that I have forgotten about brute forcing practicality.
    • mro_name 4y ago
      I think about rate-limiting from an unprivileged user perspective and saw it first at https://github.com/sebsauvage/Shaarli/blob/master/index.php#L19 https://github.com/sebsauvage/Shaarli/blob/master/index.php#.... So e.g. fail2ban is not an option. And the application has to deal with it. I care more about load/DOS than actual crack success. What means the firewall is the sensible place. Not the application. Or just take the risk, make backup/restore simple and do intrusion detection by monitoring a dedicated endpoint with e.g. https://updown.io/44q5 https://updown.io/44q5 and let things happen for the sake of simplicity. Hm. (I'm doing a federated, single-user microblog engine targeting laypersons. A proof of concept is at https://codeberg.org/mro/ShaarliGo https://codeberg.org/mro/ShaarliGo)
• mro_name 4y ago
  what's your take on tags?
  • hales 4y ago
    I love the idea of tags/categories on sites. They're an alternative navigation strategy that I particularly like using when reading people's blogs. I have not implemented tags in Minisleep's releases because, whilst doable, they are a bit messy and complex for this codebase. I want people to be able to fully understand what's going on in Minisleep so they can feel confident extending build_page.sh and adding custom script-pages themselves, not be worried they might be breaking some feature somewhere else that they don't know about yet. Currently Minisleep's philosophy is "editing one page only modifies that one page". There are no central indexes. You are free to re-arrange, delete and create folders and files yourself, the worst you will have to do is re-run build_page.sh afterwards to update hyperlinks on a page. Adding tags requires you to generate and update centralised pages regularly (eg every time a page has its tags changed or is deleted). If anyone modifies pages in a way that does not trigger these updates: things break. Another (but more minor) issue: Minisleep's page relationships are hierarchical (folders) not relational (ala SQL). Tags are a bit more relational, ie different pages are arbitrarily related. For the pages themselves this is not a problem (tags are just a list of links somewhere on the page, no need to reference external materials when generating them) but it means the central tag pages (listing other pages with x tag) need to be made by trawling through _every_ page on the site manually with no optimisation. In reality this is mostly fine, it's not really that performance demanding unless you have a wiki with thousands of pages or more (at which point you probably are not using Minisleep). I do it this way on my personal website https://halestrom.net/ https://halestrom.net/ for generating the front page index of articles and comments, with some hacked-up half indexes. It's a mess but it works, and that's exactly the sort of thing I want users to hack up and add to their Minisleep sites themselves, rather than accept as a mess from me.
    • mro_name 4y ago
      thanks, indexes indeed may provide most what's expected from tags. At a way lower cost. Wicked. (In my microblog engine I go lengths to automatically maintain redundant entries in directories e.g. https://l.mro.name/o/t/CGI/ https://l.mro.name/o/t/CGI/. But a microblog is a different story)