Authentication problems

[jrsmith]

Hi, I've been struggling with trying to get 21 to do something more than connect to the market for a couple of days, and finally began to dig into it more during my free time after the July 4th holiday. I'd like to share with you what I found.

My payments and ping service containers were failing immediately after trying to run 21 sell start --all. I attached to the containers and found the following error message:

Traceback (most recent call last):
  File "/usr/src/app/utils/login.py", line 55, in <module>
    login_21()
  File "/usr/src/app/utils/login.py", line 47, in login_21
    rest_client.login(payout_address=payout_address, password=password)
  File "/usr/local/lib/python3.5/site-packages/two1/server/rest_client.py", line 147, in login
    r = self._request(sign_username=None, method="POST", path=path, data=data, two1_auth=two1_auth)
  File "/usr/local/lib/python3.5/site-packages/two1/server/rest_client.py", line 90, in _request
    raise ex
two1.commands.util.exceptions.ServerRequestError: Received forbidden error (403). Login in with 21 login and try again.

I looked through the ping source to see where it got its auth credentials, then checked the docker container's environment vars and checked TWO1_PASSWORD for accuracy.

My password was roughly pass$word@isok^#&too, but the value stored in TWO1_PASSWORD was pass@isok^#\u0026too. I'm no stranger to python, so I assumed a unicode decode call was missing somewhere (though it looks like some kind of string interpolation might be happening too since $word is totally gone). I changed my password, started typing up this post, reauthed on the server, then tried to start the ping service again. Oddly, they still failed, and the env vars still had my old wrong password. I manually destroyed the containers and ran 21 sell start --all again, but it still had the wrong password. I uninstalled and reinstalled 21, still the same problem.

I assumed at this point that there were some leftover config files in my home dir that weren't removed during reinstall, since I wasn't prompted to create a new wallet. I grepped that dir and found my old password in .two1/services/21-compose.yaml. This file must not get updated after first creation.

(As an aside, this file is also world readable, which is probably bad.)

Updating this file directly solved my problem. I assume deleting the file altogether would have also worked.

So, to recap -

• Password encoding is busted somewhere. Not sure if it's specific to 21 or docker compose, since I've only gone so far into the code to debug as far as I needed to to get it working, but there's definitely a problem somewhere between those two.
• The generated docker compose file doesn't get updated when a password change occurs. Correct me if I'm wrong, but since this file seems to get used when creating services, and you're prompted for your password before that happens, it could be used in docker compose without needing to be stored in .two1/services/21-compose.yaml at all, perhaps substituted into a temp copy of the file after the password has been reentered by the user and then rmed after the containers are up. At the very least, that file's permissions should be 600.

I know that any docker user would also be able to pull the TWO1_PASSWORD var from an existing container, but they would need to be allowed access to the docker daemon to do that. It would be ideal if there was a way to pass this auth to the container in a way that wasn't so public, or maybe use an auth token that gets generated when the service is brought up and renewed periodically by the microservices while they're running. Just a thought.

[wbnns]

@jrsmith Hello, thanks for putting together this detailed write-up. We'll check into this and will follow back up with you soon.

[wbnns]

@jrsmith When convenient, could you please run 21 --version and post the output here?

[jrsmith]

@wbinns No problem:

21 version 3.5.1

[dongcarl]

@jrsmith Hey JR! Amazing writeup and thanks for your patience with this. I've looked into the issue and it looks like it has to do with how docker-compose processes the data it loads from our YAML files (it tries to eval $xxx as variables) and how we write our YAML files, since we're unable to change anything in docker-compose, I've gotten a full workaround/fix in the pipelines and I'll let you know when it's released! That being said, 3.5.2 should already have a fix that updates the password properly so you can try that out!

[wbnns]

@jrsmith Hello, I just wanted to send you this note to let you know that we haven't forgotten about you and will continue to keep you posted with updates in regard to this issue.

[kopyaephyohtet]

Good