Replies: 1 comment 2 replies
-
Did you read https://docs.rs/axum/0.6.20/axum/middleware/index.html#writing-middleware? The recommendation is to use https://docs.rs/axum/0.6.20/axum/middleware/fn.from_fn.html instead of making a tower::Service directly. It’s way easier. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
While I like the general design
axum
takes there is extra cost to be paid compared to other languages. This is story of how tough it was.1st I tried a standalone layer middleware and the most difficult part was figuring out how to process async validation request and pass it to next service only on success. This was exercise in figuring out how to run async validation task without building next Future. In the end a custom ResponseFuture with cloned
inner
ornext
execution step is what axum expects to do.I found an example of how above is done in
AsyncRequireAuthorizationLayer
intower-http
and I realized that I basically have to replicate its work.I tried using it directly. It was not easy to find out the underlying restrictions imposed by
AsyncRequireAuthorizationLayer
. The example and test code do not use route integration and data types were not matching.The key was in identifying that custom validator must return
UnsyncBoxBody<axum::body::Bytes, axum::Error>
. I am not fully following whyUnsyncBoxBody
is used.It all culminated in this work: https://github.com/kulak/axum-middleware/blob/main/src/jwt_auth_delegate.rs and a corresponding test app https://github.com/kulak/axum-middleware/blob/main/examples/jwt-auth-delegate/src/main.rs.
Hopefully, next one will be easier to write.
Beta Was this translation helpful? Give feedback.
All reactions