Feat: add async support for auth handler

[IA-PieroCV]

Description

This PR add the possibility to run async authenticate on AuthenticationHandler.

Summary

This PR changes adds the typing hints for Authentication handler in order to return an Identity that comes from a Sync process or a Coroutine (Async). Also, it modifies the add_auth_middleware function to run this authenticate using async.

FYI: This allows AuthenticationHandler to support async sessions on cache (on memory db like redis).

class RedisAuthHandler(AuthenticationHandler):
    """Redis Robyn auth handler using async Redis."""

    # Inheritance on abstract method allows both async and sync child methods.
    async def authenticate(self, request: Request) -> Identity | None: # Python 3.10 typing syntax
        """Authenticate Handler in Redis."""
        token = self.token_getter.get_token(request)
        if not token:
            return None

        user_id = await RedisClient.get_user_from_token(token) # <-- Important part. To the user this is just straightforward
        if user_id:
            return Identity(claims={"user_id": str(user_id)})
        return None

PR Checklist

Please ensure that:

• The PR contains a descriptive title
• The PR contains a descriptive summary of the changes
• You build and test your changes before submitting a PR.
• You have added relevant documentation Minor feature, so current API Reference explains the usage.
• You have added relevant tests. We prefer integration tests wherever possible Minor feature, so current auth testing worked for both scenarios (sync and async).

Pre-Commit Instructions:

• Ensure that you have run the pre-commit hooks on your PR.

EDIT: Add some code context

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
robyn	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 3, 2024 4:59am

[sansyrox]

Hey @IA-PieroCV 👋

Thanks for the PR but why do we need this type?

[IA-PieroCV]

Hey @sansyrox !
This is for typing complying. I'm using pyright and this is making it. Guess with mypy, pyre and others will work as well.
As the child classes can override sync method to async methods, authenticate should be awared of returning both sync result (Identity | None) and async result (Coroutine[Any, Any, Identity | None]).
Edit: Adding more context

[sansyrox]

@IA-PieroCV 👋

Should we use a type alias instead? The return type is not super readable

[sansyrox]

and what about sync support?

[IA-PieroCV]

I tested with both sync and async and both worked pretty well...
However, I'm kind of worried not showing support for both sync and async. I'll make some tests and will back with the results

[sansyrox]

Hey @IA-PieroCV 👋

I will have a proper review over the weekend 😄

[sansyrox]

Hey @IA-PieroCV 👋

I really like the implementation. Do we need to add some docs for this?

Also, would love some integration tests

[IA-PieroCV]

Hey @sansyrox !
I guess I can add a tab to the mdx documentation with "sync"/"async" if this is okey. I don't think is needed to be explicit, but to mention it briefly and show the capability. Are you okey with this approach?

About integration test, of course! I'll implement it in the next couple of hours, it doesn't seem like a problem.

[IA-PieroCV]

Hey @sansyrox!
As the middlewares are added on runtime the evaluation of coroutine cannot be made at first hand.
I know that we were discussing how endpoints could be registered at the start method and part of the PR I made on #1056 takes this approach too. This would solve this as the configuration should be implemented before registering the auth middleware.

I'm trying to look for an approach that solves this without the change on the registration approach, but this could take me some time. By now I will convert this PR to draft until I found a solution or having the endpoint registration on the start method (if it's done).

[dave42w]

Hey @sansyrox! As the middlewares are added on runtime the evaluation of coroutine cannot be made at first hand. I know that we were discussing how endpoints could be registered at the start method and part of the PR I made on #1056 takes this approach too. This would solve this as the configuration should be implemented before registering the auth middleware.

I like the approach that we basically register routes, middleware, auth, routers after app = Robyn(...) and before app.start(...)

Then in app.start(), before we call run_processes()...) we prepare everything that has been registered. This makes the registration much easier to test and it avoids any restrictions on the order developers register all the parts of their application. Once applications grow it makes it easier for whole departments with their own combinations of routes, middleware etc to be plugged into the whole with one include.

I think it is going to make the whole prepare step much easier. We choose when to process authentication, subrouters, routes etc rather than the order the code got put together.