Use selfhosted Staticman with GitLab: Part 2

This is part 2 of a five-parted series:

• Part 1 deals with the resources needed and the initial Setup with GitLab
• Part 2: I talk about how to test your staticman-configuration.
• Part 3: Add OAuth, Mailgun, Recaptcha, Antispam (to be written)
• Part 4: Deploy it on your server (to be written)
• Part 5: Integrate it with your Static-Site-Generator (to be written)

Test your staticman instance

We want to see whether our selfhosted staticman-instance actually works.

Run staticman

Let's navigate into the folder we have cloned the staticman dev-branch into and run npm run start - the console puts out Staticman API running on port 8081 depending on which port we declared in the config.development.json. Good - it works.

Test staticman

Now to test whether we have the right version of staticman we can do a simple curl-command: curl localhost:8081 - again depending on your port your staticman is running, you may need to change that number. The console should report Hello from Staticman version 3.0.0! - Very Good!

You can take each Url I post with the curl command and just enter it in your browser. Both will send a GET-request to your staticman instance. Why use curl then you ask? Because you have more control over your request - which is not as important here, but in other cases you don't need to mess around with caches and similar stuff

Now let's take this up a notch. Is it possible that we could actually post a comment yet? Theoretically we could, but let's be sure everything is set.

If you did part 1 correctly, you have your ApplicationID and your Secret and you don't know yet which purpose they serve. With them you can utilize OAuth in your commenting system - we will need that in part 3.

You need both these strings to be encrypted by your hosted staticman instance. Go ahead and run

curl localhost:8081/v3/encrypt/<your ApplicationID>

and

curl localhost:8081/v3/encrypt/<your Secret>

You'll receive two base64 encoded strings which you put in your staticman.yml file. The first one as clientId - the second one as clientSecret.

Don't forget to push your changes to your repository.

Now we're set to post our first comment - let's make a POST-request to our staticman-server! This time we won't be using curl - instead we use Postman. You may use Burp Suite if you want to use a penetration tester's tool.

Now make a POST-request which looks like this. Be sure to have each property set. The Content-Type should be set to application/x-www-form-urlencoded

When everything worked out you should get a success message like the one in the picture.

If not it could be one of three problems:

• You get the error MISSING_REQUIRED_FIELDS - lucky you, that one is the easiest to work out. You just did forget one of the required fields in your POST-request. These are defined in your staticman.yml. If you used my template from part 1, the requested fields are name, comment, email and slug. Maybe you ask why you have to pass the slug twice? Otherwhise the slug won't get stored in your generated yaml which will be pushed as a comment to your repository.
• You get Èrror during decryption (probably incorrect key). Original error: Error: error:04099079:rsa routines:RSA_padding_check_PKCS1_OAEP_mgf1:oaep decoding error. This one took me real long. I thought this one appeared because I did a lousy job when preparing the RSA private key for JSON. Nope just check your staticman.yml for wrongly inserted strings. Could be the strings you put in the two gitlabAuth-fields. For me it was the reCaptcha fields: I did not enable it, but I pasted my ApplicationID and Secret into siteKey and secret. Don't do that - just leave them empty, i.e.: "".
• GITLAB_CREATING_PR or a similar GitLab related authorization error - check your access rights of your repository regarding your bot-account. Don't forget to unprotect your master branch, so that the bot can push his changes directly to the master branch.

If you made it this far then everything is set for the next step!

Part 3 is coming soon!

Add a comment