La Suite Menshen: the Token Exchange server.

Warning

We are bootstrapping this project. Nothing is really usable in a production context at this time.

Local Development (for contributors)

Run Menshen locally for development and testing.

Warning

This setup is intended for development and testing only.

Prerequisites

• Docker
• Docker Compose
• GNU Make

Verify installation:

docker -v
docker compose version

If you encounter permission errors, you may need to use sudo, or add your user to the docker group.

Bootstrap the project

The easiest way to start is using GNU Make:

make bootstrap

This builds the Menshen and playground containers, installs dependencies, runs database migrations, and creates demo fixtures and Menshen's super user.

It is recommended to run this command after pulling new code.

Start services:

make run

As Menshen is a headless API server, once up only the admin console is available at: http://localhost:8071/admin

Default credentials (development only):

username: admin
password: admin 

Django admin

To access the Django administration console, you should create a superuser first using:

make superuser

If you have setup the project locally using the make bootstrap command, trying to create a new super user should fail as it already exists.

Tests & Linting

make test
make lint

Playground: a demo for Menshen

Menshen's repository offers a playground that can be used for demonstration purpose and serves as an example integration for source and target services using an authorization server to share their resources.

If you have already run the make bootstrap command, demo fixtures should already have been created to use the playground. If not, you can create basic demo fixtures using the eponym command:

make demo

You can start the playground using the dedicated command:

make run-playground

This should fire up two new services:

• playground-source available at: http://source.localhost:8072
• playground-target available at: http://target.localhost:8073

You can login from the source or target services using the "login" button in the page header. Once clicked, you should be redirected to the Keycloak service that is used as the identity provider for our development environment. The test user credentials are:

username: menshen
password: menshen

Once connected, you should be redirected to the original service.

If you click the login button of the second service, due to our silent login configuration, you will not be prompted again for your credentials and will be automatically redirected to this second service and logged in.

In this playground scenario, the source service (a meeting recording service) will use the target service (a drive) as a backup for its recordings. When starting both services, once logged in, the target service should be empty (no files stored for your account), and multiple recordings should pre-exist in the source service.

If you click the "Backup" button from the source service main view, a success flash message should appear on top of the page, and a new file should have been created and is now listed in the target service.

Behind the scene, the source service uses the target service resource server API to backup recordings using an exchanged token generated by Menshen 😎

Hacking with the playground

If you intend to improve or adapt the playground, we invite you to activate docker compose watch-mode using:

make watch

This will copy modified service sources and restart it automatically. It will also rebuild the service container if you update dependencies or the service's Dockerfile.

More Make targets

To check all available Make rules:

make help

License 📝

This work is released under the MIT License (see LICENSE).

While this project is a public-driven initiative, our license choice is an invitation for private sector actors to use, sell and contribute to it.