Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/palant/palant.info_commentserver

Comment management server used by palant.info
https://github.com/palant/palant.info_commentserver

Last synced: about 2 months ago
JSON representation

Comment management server used by palant.info

Awesome Lists containing this project

README 

        
This comment management server has been developed specifically for palant.info. It is unlikely to meet your exact requirements, provided here for reference only.



# Design goals



* Used by a website built on a static site generator (Hugo).

* Comments and replies stored in the  repository along with other website content.

* Pre-moderated comments, published only when approved by site owner.

* Direct replies only by site owner.

* Commenter's email address removed after moderation, notifications about replies only if provided during moderation.



# Installing



This application is most easily installed via [pipx](https://pipx.pypa.io/):



```sh

pipx install git+https://github.com/palant/palant.info_commentserver.git

```



# Running



If installed via pipx, the test server can be started with the following command:



```sh

commentserver config.ini

```



The test server will be accessible under http://localhost:5000/. The `config.ini` file should have the following entries:



    [site]

    baseurl = https://palant.info

    publicdir = /var/www/public

    queuedir = /var/spool/comments



    [github]

    user = palant

    repository = palant.info

    access_token = 1234567890abcdef1234567890abcdef12345678



    [mail]

    smtp_server = mail.example.com

    sender = [email protected]



The `access_token` value must be a GitHub access token with write privileges for the GitHub repository.



In order to run a production server, `commentserver:app` needs to be executed via the WSGI interface.



# Comment submission process



The comment submission form can be seen in `layouts/partials/components/comments.html` template in the  repository and the JavaScript code behind it is in `assets/js/comments.js`. The server receives the comment, validates it and saves it to the queue directory with a random name. The blog owner is notified with an email mentioning the URL where the comment can be reviewed.



The blog post is identified by its URI in the path. To validate the URI and retrieve additional data, the server reads the static file generated for the blog post from the server's public directory. In particular, it expects to find a `data-path` attribute on the comment form determining the path of the blog post within the original repository.



The blog owner can either approve or reject the comment in the moderation interface, optionally specifying a reply. If the comment is approved, both the comment and the reply are added to the GitHub repository. With either action the comment data is removed from the queue, and with it the commenter's email address.



# Webmention and Pingback support



This server supports receiving [Webmentions](https://www.w3.org/TR/webmention/) and its older counterpart [Pingbacks](https://www.hixie.ch/specs/pingback/pingback-1.0). The Webmention endpoint is exposed under `/mention/submit`, the Pingback endpoint under `/mention/pingback`. When a request is received, it goes through the same pre-moderation as the comments. Initially, it is only validated that the target URL points to an article that has a comment form. After that, the mention is queued and the blog owner is notified via email.



The next validation step is performed only when the blog owner opens up the review URL. Among other things, this approach prevents the interface from being [abused for DDoS attacks](https://indieweb.org/DDOS). The source URL is downloaded, the link existence is verified and page metadata is retrieved. The metadata is then used to compose “comment” data. If approved, this comment is added to the GitHub repository.



# Security considerations



To prevent CSRF attacks, comment submission is required to send `X-XMLHttpRequest` header. This ensures that it cannot be triggered by third party websites.



Comment moderation interface is only accessible with knowledge of the name under which the comment has been stored in the queue. With the name being based on 16 random bytes, bruteforcing it remotely is unrealistic.



Ideally, comments would be stored in the repository as entered. However, Hugo cannot currently sanitize untrusted Markdown content. So comments will be converted to HTML and sanitized when received by this server.



Blog owner replies will also be sanitized. This protects against the unlikely event that an attacker can gain access to comment moderation interface.