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
-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:
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.È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!
Author: Marcel Michelfelder