24 November, 2018
This is part 2 of a five-parted series:
We want to see whether our selfhosted staticman-instance actually works.
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.
Now to test whether we have the right version of staticman we can do a simple
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
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
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
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:
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
slug. Maybe you ask why you have to pass the slug twice? Otherwhise the slug won't get stored in your generated
yamlwhich will be pushed as a comment to your repository.
È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.ymlfor wrongly inserted strings. Could be the strings you put in the two
gitlabAuth-fields. For me it was the
reCaptchafields: I did not enable it, but I pasted my
secret. Don't do that - just leave them empty, i.e.:
GITLAB_CREATING_PRor 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!
Author: Marcel Michelfelder