Variables == ‘single quote’ and logs

Yesterday our team was struggling with an API call for one of our services. The client we developed for our API was getting an “Unauthorized”  message, to a request that worked pretty fine in the dev environment. At first we thought that our token was not valid so we started to see what was happening.

After some unsuccessful tries to solve it, we decide to read again the error message on our API server.  And we found out that it was pretty straight forward:

Identity server rejected authorization necessary to fetch token data

The problem was not our client token but actually our API didn’t have the right credentials to do the token validation

Checking our confs, we found out that one of our passwords had only 6 chars. What? That is not what we do! What happened? This is what happened

$ export API_PASSWORD=123$abc#de

Would like to try this on your terminal? Type this:

$ export API_PASSWORD_ABC=123$abc#de
$ echo $API_PASSWORD_ABC
123#de

So, what happened? YES! Your shell thought $abc should be replace by a variable. And since you probably don’t have it, it will replace $abc with an empty string. Ending up with a result like this: 123#de.

So, what did we do?

$ export API_PASSWORD_ABC=’123$abc#de’

Singles quotes! Inside single quotes, everything is literal but single quotes itself and the escape char (\)

Lessons learned:

  1. Be careful when exporting strings. If possible, always use single quotes
  2. LOGS MATTERS! Good log messages can save hours of work!

If you read until here, thanks for you time and if it helped you somehow, or if you would like to point something out, please, feel free to drop me a comment.

Using curl to test 1 server in a cluster

Hello!

Today I was checking some ssl certificates and I realized that I couldn’t test an specific server on my web cluster server  using this:

$ curl -H ‘Host: serverhost.com’ https://192.168.32.1/path

The reason is SNI. I won’t get into details but you can see more here.

So, to do that request, you can use:

$ curl -v --connect-to serverhost.com:443:192.168.32.1:443 https://serverhost.com/path

–connect-to seems to be a very useful option to solve that kind of issue.