doing auth with fastapi + idom

[acivitillo]

Completely experimental, never seen this before, but it works. The idea is to move auth to the FastAPI API layer and store the access_token in the idom state.

Is it crazy though? I mean it's relatively simple to reason about in idom, but I wonder if this makes sense. I guess the user would have to login every time the websocket connection is lost.

Better ideas? It would probably be convenient for idom to store some state in a client cookie.

from fastapi import FastAPI
import requests
from idom import component, hooks, html, run, vdom, web
from idom.server.fastapi import PerClientStateServer


@component
def Authenticate(username: str = "", password: str = ""):
    user, set_state = hooks.use_state({"name": username, "password": password})

    if username != "":
        print(username, password)
        data = requests.post(
            f"http://127.0.0.1:8000/token",
            data={"username": username, "password": password},
            headers={
                "accept": "application/json",
                "Content-Type": "application/x-www-form-urlencoded",
            },
        )
        user["access_token"] = data.json()["access_token"]
        set_state(user)
        return Result(user)
    else:
        return html.div(
            html.form(
                html.input({"name": "username"}),
                html.input({"name": "password"}),
                html.button("Login"),
            ),
            Result(user),
        )


@component
def Result(user):
    try:
        data = requests.get(
            "http://127.0.0.1:8000/users/me",
            headers={"Authorization": f"Bearer {user['access_token']}"},
        )
        return html.p(data, user["name"])
    except KeyError:
        return html.p("")


run(Authenticate, port=3000)

[rmorshea]

There should definitely be a better way of adding authentication in IDOM. @Archmonger is using a similar strategy in a project based on django-idom. This works in Django IDOM for two reasons:

1. We're passing info about the websocket connection as an argument to the root component
2. This still requires some sort of static login page where you save auth state in the client (correct me if I'm wrong @Archmonger).

We can solve 1 in IDOM core with the upcoming use_context hook:

from idom.server.fastapi import RequestContext
from idom import component, use_context

@component
def AuthenticatedView():
    request = use_context(RequestContext)
    # use some sort of auth token on the request

For 2 though, I haven't really had time to figure out a good way of saving client-side state. It's certainly possible, the question is what the API should be:

• Custom components for each auth solution?
• A generic way of saving client-side state?
• Built-in auth solutions for each server implementation?

Not having thought about this much, I'd lean towards the custom component solution, at least initially, since that wouldn't require any big changes.

[Archmonger]

My login is currently fully HTTP and skips IDOM.

In terms of logout...

On the Django side, I'm handling a lot of stuff by creating event driven invisible iframes. Loading the iframe triggers server side logout, and then a client side page refresh (on the parent frame).

It's janky right now but we'll figure out a better solution with time.

[acivitillo]

@Archmonger how does your HTTP login work? How will IDOM components know the user is logged?

[rmorshea]

Presently, IDOM does not expose the request associated with the underlying websocket connection. Ultimately I intend to do this with contexts. A usage might look like:

from idom import component, use_context
from idom.server.fastapi import RequestContext

@component
def MyComponent():
    request = use_context(RequestContext)
    ...

Unfortunately I've been bogged down with work and more pressing bug fixes so I haven't managed to get contexts across the finish line.

[Archmonger]

Within Django, the HTTP session is shared with the websocket session. So authenticating on a traditional HTTP page also authenticates a websocket indirectly.

The second part to that story is Django IDOM propagates the request context via positional args. That allows me to do things such as accessing the authenticated user's object.

[Archmonger]

Also @rmorshea to clarify your "statement 2" on this post, I'm doing login entirely through traditional Django HTTP.
I don't have to do this though, since Django websockets support login/logout methods.

I choose this route since there's added efficiency in serving the login page staticly (mostly caching related).

[acivitillo]

thanks for this, sounds like what I need. Question, what will the RequestContext object contain?

…

On 14 Feb 2022, at 19:08, Ryan Morshead ***@***.***> wrote:  Presently, IDOM does not expose the request associated with the underlying websocket connection. Ultimately I intend to do this with contexts. A usage might look like: from idom import component, use_context from idom.server.fastapi import RequestContext @component def MyComponent(): request = use_context(RequestContext) ... Unfortunately I've been bogged down with work and more pressing bug fixes and so I haven't managed to get contexts across the finish line. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.

[Archmonger]

It's likely going to vary from framework to framework. At least within Django-IDOM it currently contains a scope and some basic websocket methods such as disconnect

[rmorshea]

It's likely going to vary from framework to framework.

Correct. For FastAPI we will probably give direct access to the starlette.websockets.WebScoket object which itself contains the ASGI scope.

[acivitillo]

so @rmorshea let me understand the flow

1. the user logs via a normal fastapi page
2. on successful login fastapi stores a token into the user cookie
3. the Websocket scope now has all the info stored in the cookie
4. so our scope populates our context state, now we can use that state in the app for auth and other things

correct?

[rmorshea]

Correct.

There ought to be a more integrated approach to authentication in the long-term, but I'm not especially knowledgeable when it comes to security, and so would be nervous about implementing anything myself without guidance from someone with more expertise.

[acivitillo]

I have noticed use_context was released, is it possible to use it with fastapi or sanic already to fetch the websocket context?

[rmorshea]

To that end, maybe the solution here is to require that all implementations have a use_cope hook that literally returns the WSGI/ASGI scope dict. An implementation may provide more hooks (e.g. use_websocket or use_request), but those are not guaranteed to be exist for all implementations.

[Archmonger]

Agreed, but if we're expanding out past one function I'd propose the syntax for this to be

from idom.server.flask import Scope

scope = use_context(Scope)

[rmorshea]

Good idea.

[rmorshea]

So, turns out it's expedient to only require the existence of a use_scope hook since some implementations should just do:

def use_websocket() -> WebSocket:
    """Get the current WebSocket object"""
    websocket = use_context(WebSocketContext)
    if websocket is None:
        raise RuntimeError("No websocket. Are you running a Starllette server?")
    return websocket


def use_scope() -> Scope:
    """Get the current ASGI scope dictionary"""
    return use_websocket().scope

[rmorshea]

The work on this is nearly complete - just updating docs to reflect the changes.

[acivitillo]

I was wondering if we could handle auth in a FastApi application and somehow pass the logged user information down to IDOM?

https://idom-docs.herokuapp.com/docs/guides/getting-started/running-idom.html?highlight=embed#embed-in-an-existing-webpage

[sylvoslee]

On fastapi, I have used middleware to get the request header https://github.com/tomwojcik/starlette-context

[rmorshea]

@acivitillo have you gotten a chance to try out 0.38.0-a1 and if so, would that release be sufficient for you to proceed with development while I'm on vacation? I'm thinking that for a 0.38.0 release I'd like to complete #721, #720, and maybe #653.

[acivitillo]

we are testing it with @liberty-rising. The use case we are working on is user logging to a FastApi page via GitHub login and passing all the GitHub user info we receive from the login to embedded IDOM thru use_scope. I think we'll need another 2-3 working days to give you an answer, but it looks promising as we were able to get basic auth working through use_scope very quickly.