DEV Community: Casey Juanxi Li

Adding Isso comments to a Ghost blog on AWS Lightsail

Casey Juanxi Li — Sun, 06 Dec 2020 22:56:19 +0000

I really like Isso. It's a free, open-source, self-hosted comment server. It's a great lightweight alternative to Disqus, which contains too many trackers.

This post will walk through adding Isso to a new project of mine, affect.blog. This is a low-cost Ghost blog, hosted on AWS Lightsail.

Pre-reqs

The process is quite easy, but requires basic familiarity with the Linux shell and editing Ghost template HTML.

If you have never edited files via the Linux command line before, I suggest using nano.

Install Isso and set PATH

From the Lightsail console, SSH into your instance:

The official Isso docs recommend using virtualenv, but I didn't bother because I have no other Python services running on the machine:

sudo apt-get install python-dev sqlite3 build-essential
pip install isso

This may install the isso executable to a non-standard directory which won't be on your PATH. You'll be notified of this location.

In my case it was /home/bitnami/.local/bin, so I added the following to my ~/.bashrc:

export PATH="/home/bitnami/.local/bin:$PATH"

If you missed the path, run pip show isso and look at the Location. The bin/isso executable should be somewhere along that path:

bitnami@ip-123-45-6-78:~$ pip show isso
Name: isso
Version: 0.12.2
Summary: lightweight Disqus alternative
Home-page: https://github.com/posativ/isso/
Author: Martin Zimmermann
Author-email: info@posativ.org
License: MIT
Location: /home/bitnami/.local/lib/python2.7/site-packages

When that's done (don't forget to source ~/.bashrc if you changed it), verify that you can run isso from the shell:

bitnami@ip-123-45-6-78:~$ isso
usage: isso [-h] [--version] [-c /etc/isso.conf] {import,run} ...
isso: error: too few arguments

Great. The Isso executable is working, and it's telling us that it expects a config file.

Make a config file

I made mine in the home directory for simplicity:

cd ~
touch isso.cfg

In isso.cfg I pasted the following:

[general]

dbpath = /home/bitnami/comments.db

host = https://affect.blog

[server]
listen = http://localhost:8080
public-endpoint = https://affect.blog/isso/
reload = off
profile = off

[guard]
enabled = true
ratelimit = 2
require-author = false
require-email = false
direct-reply = 10
reply-to-self = true

Give it a whirl:

isso -c ~/isso.cfg run

You should see:

bitnami@ip-123-45-6-78:~$ isso -c isso.cfg run
2020-12-06 20:35:48,893 INFO: connected to https://affect.blog

Great. Isso is now running in the foreground.

Move isso to a background process

More on init scripts later, but for now let's just get things working.

We don't want the Isso process to die when we close the terminal, so hit Ctrl-Z to suspend it, and then run bg to move it into the background:

bitnami@ip-123-45-6-78:~$ isso -c isso.cfg run
2020-12-06 20:35:48,893 INFO: connected to https://affect.blog
^Z
[1]+  Stopped                 isso -c isso.cfg run
bitnami@ip-123-45-6-78:~$ bg
[1]+ isso -c isso.cfg run &

We can now safely close the Lightsail terminal, and Isso will keep running at port 8080 (or your port of choice).

Setting up Apache proxy

Isso is now running at port 8080, but we need to proxy it to a public url.

The Isso documentation gives an example for Nginx, but the Lightsail Bitnami Ghost stack uses Apache. Luckily, I was able to find an example Apache config in this blog post.

Similar to this author, I wanted to serve Isso at affect.blog/isso/ instead of a new subdomain (isso.affect.blog). This is to avoid having to make a new SSL certificate.

Add the following lines to the end of /opt/bitnami/apache2/conf/httpd.conf:

# Proxy for Isso commenting
ProxyPass /isso/ http://localhost:8080/
ProxyPassReverse /isso/ http://localhost:8080/

Use sudo /opt/bitnami/ctlscript.sh restart or the bn-helper tool to stop and restart all your services. Now verify that Isso is accessible at https://affect.blog/isso/:

This is actually great! The request fails because we haven't passed a uri, but we are successfully serving up Isso. (If this URL were set up incorrectly, we would see a "404 Page Not Found" handler from Ghost.)

You can verify that the expected JS resource is available at /isso/js/embed.min.js. This should load a minified file:

Inject Isso script to header

The quickest way to inject the Isso script into the header of your entire site is to use Ghost's Code Injection feature:

Drop your script tag in here:

<script data-isso="//affect.blog/isso/"
    src="//affect.blog/isso/js/embed.min.js">
</script>

Quick page test

Make a new page to test and add the following HTML snippet. (We'll put this in a post template later):

<section id="isso-thread"></section>

The HTML tag won't render to anything visible in the editor, but don't worry. Save the page, publish it, and view. If all went well you should see this:

Congrats! Your Isso comment server is working.

Adding comments to a post template

Of course you don't want comments on just one page, but on all of your posts. This is achieved by adding the above tag to your post template. Ghost provides detailed instructions here.

The ideal place to do this will depend on your Ghost template. Here's how I did mine:

Download your theme to a .zip and unzip it:

Find post.hbs, make a copy, and edit

You must start the new filename with custom- in order for Ghost to pick up the template:

Insert your Isso section

I opted to remove the default Disqus section and replace it with my Isso section instead. I also placed a new CSS class on the section to make it easy to style these comments using Code Injection:

Re-upload theme, and apply custom template

Now zip up your edited theme using the same name, upload it (overwrite your current theme), and change one of your posts to use the new custom template:

Give the post a refresh, and voila - here is the result:

If everything looks good, you can either update all your current and future posts to use the new template, or apply the change to post.hbs.

Note: Isso loads and stores comments based on page URL

The slug is the portion of a post's URL after the main slash:

This means that if you add some comments to a page and then change its slug, the comments stored under the old slug will no longer appear for that page.

The comments are still in the database, however. Deleting or editing a Ghost page does not affect its Isso comments at all.

If you change the slug back, or make a new page with the same slug, the comments will re-appear.

Use a process manager to keep it running

Running Isso as one process in the background was fine to get started, but is not great for long-term use. You don't want your blog to be left comment-less if the process dies when you're not around to restart it.

The Isso docs have some suggestions. I had trouble using systemd, but supervisor did the trick. I placed the conf file my home directory:

pip install supervisord
echo_supervisord_conf > /home/bitnami/supervisord.conf

Add this [program] section to supervisord.conf (reference):

[program:isso]
command = /home/bitnami/.local/bin/isso -c /home/bitnami/isso.cfg run
directory = /home/bitnami/isso
user = bitnami
autostart = true
autorestart = true
stdout_logfile = /home/bitnami/isso/isso.log
stderr_logfile = /home/bitnami/isso/isso_err.log

And kick it all off:

supervisord -c /home/bitnami/supervisord.conf
supervisorctl start isso

To check that all is working as intended, find the process running on port 8080, kill it, and verify that it restarts immediately with a new PID:

bitnami@ip-123-45-6-78:~$ sudo netstat -lpn |grep :8080
tcp        0      0 127.0.0.1:8080          0.0.0.0:*
LISTEN      14196/python        
bitnami@ip-123-45-6-78:~$ kill 14196
bitnami@ip-123-45-6-78:~$ sudo netstat -lpn |grep :8080
tcp        0      0 127.0.0.1:8080          0.0.0.0:*
LISTEN      14417/python        
bitnami@ip-123-45-6-78:~$

👍

That's it!

I was really happy to find a free, open-source commenting solution, without the bloat and privacy concerns of Disqus.

If you were considering using Isso for your Ghost blog, I hope this post has helped. Please feel free to leave questions and comments below!

Setting up a new Ghost blog for $3.50 a month with AWS Lightsail

Casey Juanxi Li — Wed, 14 Oct 2020 00:17:27 +0000

At $3.50 per month, running a Ghost blog on the smallest AWS Lightsail machine using a Bitnami image is an attractive alternative to paying $29 per month for Ghost's Basic plan. I prefer Ghost to Wordpress - it's lighter and prettier. 😏

The documentation at https://aws.amazon.com/blogs/compute/building-a-photo-diary-ghost-on-amazon-lightsail/ gets you 90% there in an hour or so, with a custom domain. It does have a few typos and odd quirks - I'll make a note of my hiccups:

"Not Secure": setting up https

Without a TLS or SSL certificate you get that sketchy little "Not Secure" notification in your browser bar - which is not really acceptable nowadays. 😷

The documentation points you to a tutorial for setting up a certificate using Let's Encrypt in relation to NGINX, which is sort of correct, but requires some tweaks. Read on.

/opt/bitnami

SSH into your instance:

Every useful tool can be found at /opt/bitnami.

(Confusingly, there is also a /home/bitnami/stack/ with similar contents. Do not run tools from there.)

Run the bnhelper-tool as a superuser at /opt/bitnami. You'll need sudo privileges for many of the downstream tools that it runs:

cd /opt/bitnami
sudo ./bnhelper-tool

Set up a Let's Encrypt certificate for HTTPS

"Set up Let's Encrypt" runs the bncert-tool, which you can also just run directly.

If you get an error saying ...server.crt' does not exist or is empty, you'll need to generate it using Certbot and symlink the created .pem files. Follow Steps 2-7 in the Amazon documentation, but keep reading as we'll need to adapt the tutorial for Ghost.

To pass the DNS challenges, add your TXT records under Home > Networking > DNS Zones:

After step 6, Certbot will generate two .pem files which need to be symlinked to the location where the bncert-tool will look for them. Note that this differs from the NGINX-specific path given in Step 7 of the Amazon tutorial:

sudo ln -s /etc/letsencrypt/live/$DOMAIN/privkey.pem /opt/bitnami/apps/ghost/conf/certs/server.key
sudo ln -s /etc/letsencrypt/live/$DOMAIN/fullchain.pem /opt/bitnami/apps/ghost/conf/certs/server.crt

Once your server.crt is in the right place, run the bncert-tool, and you should be on your way.

Start/stop services

In bnhelper-tool you can also start/stop/restart your services (ghost, apache, mysql). This is just a wrapper for ./ctlscript.sh status, ./ctlscript.sh start, ./ctlscript.sh stop:

Remove Bitnami "Manage" banner

You can also remove the little "Manage" banner that appears in the bottom right. This actually runs sudo /opt/bitnami/apps/wordpress/bnconfig --disable_banner 1:

You may get a child process exited abnormally error. Inexplicably, something that I did caused bnconfig to be renamed to bnconfig.disabled. I'm not sure why.

Renaming it back does the trick - I had to do this a couple of times:

sudo mv /opt/bitnami/apps/ghost/bnconfig.disabled bnconfig

Serve it via a CloudFront distribution

The final thing which isn't mentioned in the tutorial is serving the site via a CloudFront distribution. If you've never used a CDN, the quick and dirty idea is that multiple copies of your site are stored around the world for quick access from any browser - and these copies are updated on a regular basis.

Fortunately, AWS' documentation for this is up to date. A CloudFront distribution will add $2.50 per month to your costs, though the entire first year is free - not bad.

To sum up

All in all, this is much easier than setting up from scratch on AWS (trying to tie together Ghost, EC2, Route 53, CloudFront, etc). Lightsail puts all these button clicks in the same place and provides a handy Bitnami image which (almost) works perfectly out of the box. The documentation isn't perfect, but it'll do.

If $29/month for Ghost seems a little pricey for a blog (which it did to me), this is a great way to still have a self-hosted setup on the cheap, with minimal config faff.

Any questions, feel free to ask below!

Firebase Cloud Firestore permissions: don't do "allow read, write: if true;"

Casey Juanxi Li — Mon, 17 Aug 2020 13:30:16 +0000

Say you're using Firebase with Cloud Firestore to handle user login and registration for a React Native app. You have the following handler for a user registration button: (Credit: this freeCodeCamp tutorial).

const onRegisterPress = () => {
        if (password !== confirmPassword) {
            alert("Passwords don't match.")
            return
        }
        firebase
            .auth()
            .createUserWithEmailAndPassword(email, password)
            .then((response) => {
                const uid = response.user.uid
                const data = {
                    id: uid,
                    email,
                    fullName,
                };
                const usersRef = firebase.firestore().collection('users')
                usersRef
                    .doc(uid)
                    .set(data)
                    .then(() => {
                        navigation.navigate('Home', {user: data})
                    })
                    .catch((error) => {
                        alert(error)
                    });
            })
            .catch((error) => {
                alert(error)
        });
    }

The firebase.auth().createUserWithEmailAndPassword() method is called to perform the actual user creation. After hitting the button you can see your new user being added to the Firebase console:

But what if you hit the following error?

FirebaseError: [code=permission-denied]: Missing or insufficient permissions

Many top-voted answers on StackOverflow recommend setting unsafe rules to solve the problem. Here's a common example:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  } 
}

This is bad. allow read, write: if true; does exactly what it says: It allows everyone (yes, everyone on the internet) to read and write to any document in your Firebase store. This is not appropriate for production.

Despite these warnings, such answers still float to the top of every StackOverflow thread on the topic, for the simple reason that it "solves" the problem for "testing purposes". But what happens after "testing"?

I found the mess of answers and the official Firebase documentation somewhat confusing to wade through. I hope the following will help.

Where to set rules?

It wasn't obvious to me. They are here (ensure you are in Cloud Firestore and not Realtime Database):

Let's look at some of the suggested solutions from StackOverflow or the Firebase documentation and see what each is actually doing:

Default: allow open access for 30 days

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if
          request.time < timestamp.date(2020, 9, 16);
    }
  }
}

This is the default rule set that you are given when you set up your Firebase project and add a Cloud Firebase database: it allows open access to everyone for 30 days, and then will deny access to everyone.

Some answers suggest simply pushing this date forward. This is clearly as bad as setting allow read, write: true. This is not a permanent solution.

Allow read/write by any authenticated user

Another common suggestion is this:

// Allow read/write access on all documents to any user signed in to the application
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.auth != null;
    }
  }
}

Better, if you are comfortable with any authenticated user being able to read and write to anything. However, I am making a registration handler - which means anyone can make an account and become an authenticated user. Let's keep looking.

Content-owner only access

Firebase documentation then suggests this for content-owner only access:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{userId}/{documents=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId
    }
  }
}

Seems perfect, right? Except this literal rule won't work for my registration handler either. A mindless copy-paste won't do here: some_collection does not exist. In fact, in a new Firebase Cloud Firestore, no collections exist:

If you recall from the handler above, the then() callback accesses a Firestore collection called users:

const usersRef = firebase.firestore().collection('users')
                usersRef
                    .doc(uid)
                    .set(data)

So the final non-obvious step is to ensure that your rule and the firebase.firestore().collection() call are actually referencing the same collection.

The collection doesn't need to exist; you just need a rule matching it

There is no need to create an empty users collection ahead of time. The firebase.firestore().collection('users').doc(uid).set(data) call simply has to find a matching ruleset. In this case, the match is /users/{userId}/{documents=**}.

If the users collection does not exist, it will be created.

Note that a typo (collection('Users'), collection('user')) would result in a permission error - not because the collection doesn't already exist, but because there is no matching ruleset to allow the write.

You can separate read and write rules

And finally, read and write rules can be separated into their own conditions. For example, the following will allow any authenticated user to read data for any document in the users collection. But they can only write to (create/update/delete) their own:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /users/{userId}/{documents=**} {
      allow write: if request.auth != null && request.auth.uid == userId;
      allow read: if request.auth != null;
    }
  }
}

Lastly, I recommend looking at your newly created documents to understand their structure:

Use the Rules Playground to test rules

Note in this example, authentication with uid=jill cannot write to the path users/jack. The line responsible for the write deny is highlighted:

But authentication with uid=jill can read from path users/jack, and the line allowing this is highlighted as well:

No more nuclear option

I hope this helped clarify use of Cloud Firestore rules, and allows you to steer away from the unnecessarily broad allow read, write: if true; option. Please feel free to leave comments below.