1. 12
  1. 9

    To anyone else with hand-rolled comments on their blog/site: How do you prevent spam posts? Are you approving each comment? Do you have any counter-measures for scripted blasts of comments?

    1. 12

      Actually the biggest spam-stopping measure for me was putting the comment form in JavaScript instead of hard-coded into HTML. (As seen in the https://sive.rs/shc post.)


      Before that one change, I used to get 20 spam-bot posts a day. Moved it to be loaded by JavaScript when the browser window reaches the bottom. And voilà. Now I get maybe one a month.

      1. 3

        Hand-rolled and simple on my site. No javascript and no SQL.

        My logs so show lots of spam attempts. Only about 3 or so have ever gotten through over the years (and I suspect they were done manually by humans, not bots).


        I use a few nonstandard form fields (namely a hardcoded one word captcha the user has to type out and then a hidden field that has to stay empty).

        As a final layer of defence I have rate limiting, both per-ip and global. I’ve never had this hit other than by myself during testing. It’s designed so that if someone does bot my site then they can only get a few comments in before hitting limits, allowing me to fix it at my leisure.

      2. 6

        Not sure what this buys vs. just stuffing the HTML into a Redis cache.

        Like with a fully static site, what you buy vs. using Redis or a CDN with stale while revalidate is operational simplicity, transparency about the state of the content, ability to grep through all the files on disk (I used this last week to figure out how many pages still use the legacy CSS file on my static site), easier to ensure P99 is good, etc. etc.

        What does stuffing the HTML into Postgres buy here? Just the time to render some HTML, right? But that’s pretty fast once you have the data, no?

        1. 5

          IMO too much DB to be static. For static add an iframe and show a static comments feed (RFC 4287/atom) per post. The feed may be generated manually (low volume) like at my blog[1] or from flat files like at a guestbook[2] starting with a mere dump of the comment html form post request.

          [1] https://blog.mro.name/2009/08/nsdateformatter-http-header/
          [2] https://codeberg.org/jugendhacktlab.qdrei.info/gaestebuch/src/branch/master/var/spool/form2xhtml/dumps/msg

          1. 2

            Yeah sorry this post lacked a little context: I have a very PostgreSQL-driven system on my backend so this was partially just my way of playing with NOTIFY and LISTEN, because I have other web apps that edit and delete these same comments.

          2. 4

            I was on-board until I got to the Javascript bit. It’s a shame they don’t regenerate the served-page as partof the NOTIFY step, then you wouldn’t have a javascript requirement to view comments.

            1. 5

              There’s an alternative approach further down which eliminates the need for javascript that involves writing the comments directly into the HTML file

              1. 4

                This is really what I was expecting when I saw “static comments”. In theory, you could POST data to an endpoint, and code a server to write that data to HTML. But this is just an implementation detail, the fact remains that most of the content is HTML.

                It’s a shame they don’t regenerate the served-page as part of the NOTIFY step

                Without something to protect you from serving a 404 in the moment of time that the file is being rewritten, it’s definitely possible to encounter weird temporary errors by doing things this way. It happens to me a lot when I’m writing documentation and watching files in my app directory for changes…you’re pretty much guaranteed to hit an error every once in a while because it just hasn’t gotten around to generating that file yet. I think solutions like Next.js may handle this at the app server level, because they can block the request until the new file is done generating, but that of course requires a server and edges on the JAMstack side of things rather than fully static “web 1.0” :D

                1. 5

                  Without something to protect you from serving a 404 in the moment of time that the file is being rewritten

                  Sounds like an issue with the site-generator tool. Ideally it would build the site into a new directory and then atomically replace the old directory with the new one, instead of deleting the directory first and then rebuilding it.

                  1. 2

                    This was a documentation generator (typedoc --watch), so technically not designed for that purpose…but the fact that I was experiencing made me realize that it’s not quite as easy as just rewriting an existing file in place. What you describe definitely sounds like it will work better, especially for most static generation use cases.

                  2. 3

                    In theory, you could

                    so you can in practice: https://codeberg.org/mro/form2xml

                  3. 2

                    Yes, it’s not a fully static site with this little bit. But in this case I totally don’t mind. Derek’s site is really, really minimal, and even the use of Javascript is minimal. So how his comments work is they’re NOT loaded initially. And only if you scroll down to bottom, it’ll trigger a load - both comments and the new comment form. It’s quite neat, old school use of JavaScript.

                    1. 2

                      Thanks. My other comment here - https://lobste.rs/s/byail8/static_html_comments#c_fongzy - explains why I did that, even though I’m generally averse to JavaScript: it stopped spam-bots.

                  4. 3

                    I agree. (I’m the author.) I posted this as a response to someone asking by email how I do comments.

                    As I was writing it up, though, I thought, “Huh. There’s actually a much simpler way.” — the way you describe.

                    But for now I just posted how I do it now, and in the future if I change it I’ll write it up again.

                    1. 1

                      sorry for the very-late reply, I’ve just seen my inbox after a hiatus but I wanted to add (lest my original comment seem too negative/snarky) that this was a very interesting article, it solves a problem I still have and so I’m likely to come back to it. Thanks!

                  5. 3

                    Ah. Took me far too long to realise this is comments in the feedback sense rather than the <!-- --> sense.

                    1. 2

                      Are there other wiki compilers like ikiwiki?

                      1. 1

                        This isn’t quite the setup I picture regarding a “static html website” (since it requires a backend and a database running on the web server), but it’s an interesting approach to turn a normally database backed feature into a static one

                        1. 1

                          static =/= files. Static means not dynamic, i.e., no content is generated on-the-fly.