Heimdallr v2

[styvane]

This PR is an alternate implementation for the Heimdallr service.

It addresses the following issues while keeping existing features.

• Improve configuration management
• Keep Secret secret
• Better Error handling
• Migrate from Warp to Axum to simplify HTTP handlers and routes.
• Additional minor improvements

[Sbcdn]

Hey @styvane ,

First of all: Good Job! :)

Is a nice service, better structured and documented as the v1 in any case!
The advantage of axum over warp is for me still a taste thingy up to now :)
One thing which would be a big plus would be an automatic swagger for api documentation, does this exist for axum?
For warp there is rweb which tries to plug swagger on top of warp but it works medium, you have an idea?

There is a conflict on the "regex-syntax" version can we just use the latest (i think 7.5) or is there a dependency issue to 6.29 ?

[Sbcdn]

Nice!

Axum seems to lean on nest-js architecture, no ?

[amab8901]

I like the way you documented everything 👍 what about unit tests?

[styvane]

Hey @styvane ,

First of all: Good Job! :)

Is a nice service, better structured and documented as the v1 in any case! The advantage of axum over warp is for me still a taste thingy up to now :) One thing which would be a big plus would be an automatic swagger for api documentation, does this exist for axum? For warp there is rweb which tries to plug swagger on top of warp but it works medium, you have an idea?

There is a conflict on the "regex-syntax" version can we just use the latest (i think 7.5) or is there a dependency issue to 6.29 ?

Thank you for the feedback, Axum does not have a way to automatically generate OpenAPI documentation at the time of this writing see tokio-rs/axum#50 . Maybe we can utoipa for that.

There is a dependency in the chain that depends on regex-syntax 6.29 that is why. We don't use regex-syntax explicitly

[styvane]

I like the way you documented everything 👍 what about unit tests?

Thank you for looking into it, and you're right about testing.

Regarding the API testing, we are currently not injecting a client into the handler; we can do that by having something like a ClientService trait for odin that we will implement and use in our TestApp This will automatically take care of any I/O issue for testing.

For the API tests, look into the tests/api module.

I will unit-test the features that do not rely on the test client.

[styvane]

@amab8901 I've add a test for the Claims extractor and fixed a bug in the process. See 8d57a5d Thank you!