python-pvas-pttbackend's Introduction

pttbackend

Keeps track of mumble instances ordered by people in different contexts

Docker

For more controlled deployments and to get rid of "works on my computer" -syndrome, we always make sure our software works under docker.

It's also a quick way to get started with a standard development environment:

docker-compose -p pttbackend -f docker-compose_local.yml -f docker-compose_local_reload.yml up

Note that you need jwt.pub from the a11napi instance you're using to get your auth tokens (/api/v1/tokens/pubkey)

SSH agent forwarding

We need buildkit:

export DOCKER_BUILDKIT=1

And also the exact way for forwarding agent to running instance is different on OSX:

export DOCKER_SSHAGENT="-v /run/host-services/ssh-auth.sock:/run/host-services/ssh-auth.sock -e SSH_AUTH_SOCK=/run/host-services/ssh-auth.sock"

and Linux:

export DOCKER_SSHAGENT="-v $SSH_AUTH_SOCK:$SSH_AUTH_SOCK -e SSH_AUTH_SOCK"

Creating a development container

Build image, create container and start it:

docker build --ssh default --target devel_shell -t pttbackend:devel_shell .
docker create --name pttbackend_devel -v `pwd`":/app" -it `echo $DOCKER_SSHAGENT` pttbackend:devel_shell
docker start -i pttbackend_devel

pre-commit considerations

If working in Docker instead of native env you need to run the pre-commit checks in docker too:

docker exec -i pttbackend_devel /bin/bash -c "pre-commit install"
docker exec -i pttbackend_devel /bin/bash -c "pre-commit run --all-files"

You need to have the container running, see above. Or alternatively use the docker run syntax but using the running container is faster:

docker run --rm -it -v `pwd`":/app" pttbackend:devel_shell -c "pre-commit run --all-files"

Test suite

You can use the devel shell to run py.test when doing development, for CI use the "tox" target in the Dockerfile:

docker build --ssh default --target tox -t pttbackend:tox .
docker run --rm -it -v `pwd`":/app" `echo $DOCKER_SSHAGENT` pttbackend:tox

Production docker

There's a "production" target as well for running the application, remember to change that architecture tag to arm64 if building on ARM:

docker build --ssh default --target production -t pttbackend:amd64-latest .
docker run -it --name pttbackend pttbackend:amd64-latest

Development

TLDR:

Create and activate a Python 3.8 virtualenv (assuming virtualenvwrapper):
```
mkvirtualenv -p `which python3.8` my_virtualenv
```
change to a branch:
```
git checkout -b my_branch
```
install Poetry: https://python-poetry.org/docs/#installation

Install project deps and pre-commit hooks:

poetry install
pre-commit install
pre-commit run --all-files

Ready to go.

Remember to activate your virtualenv whenever working on the repo, this is needed because pylint and mypy pre-commit hooks use the "system" python for now (because reasons).

python-pvas-pttbackend's People

Contributors

Stargazers

Watchers

python-pvas-pttbackend's Issues

Add Bearer Authentication support

The PTT backend currently is a microservice that handles user authentication using cookies. However, we need to update it to use Bearer Authentication instead. This will improve security and provide better support for modern web applications.

To achieve this, we need to do the following:

Update the microservice to support Bearer Authentication.

Once these changes are made, the microservice will support Bearer Authentication and any frontend applications that use it will be able to authenticate using a Bearer token.

The Bearer auth support is added in pvarki/python-pvas-arkia11napi#4

Rename DBInstance schema name to include microservice name

We currently have multiple microservices that use the same schema name, DBInstance. However, the contents of each schema are different, which can lead to confusion and potential errors. To resolve this, we need to rename the schema name to include the microservice name.

Specifically, we need to rename the DBInstance schema in the TAK microservice to TAK_DBInstance and the DBInstance schema in the PTT microservice to PTT_DBInstance. This will make it clear which microservice the schema belongs to and prevent any confusion or errors that may occur due to the same name being used for different contents.

To achieve this, we need to do the following:

Update the PTT microservice to use the new schema name, PTT_DBInstance.
Update any dependent code, such as SQL queries, to use the new schema names.

Once these changes are made, the DBInstance schema in each microservice will be renamed to include the microservice name, making it clear which schema belongs to which microservice.

Please let me know if you have any questions or concerns about this update.

pvarki / python-pvas-pttbackend Goto Github PK