Dioxus 0.6 authentication and extractors

[niclashoyer]

I'm a bit lost on how to use extractors correctly with 0.6 without replicating the whole launch function body from dioxus_fullstack.

The documentation still links to the 0.5 tag: https://github.com/DioxusLabs/dioxus/blob/v0.5/packages/fullstack/examples/axum-auth/src/main.rs

Is there any way to pass layers to the LaunchBuilder or do we really need to replicate everything from here for now?

[brianmay]

At the axum level (not sure if this helps or not), you set up middle ware to do the authentication "the way you want"(tm).

Example is a bit different from the above example because that uses the Session object; There is also a custom extractor used. I have tried to simplify things. I assume User is a struct.

This will set an Axum extension using something like:

request.extensions_mut().insert(user);

And use that value to call inner layers:

let mut response = inner.call(request).await?;

I think you are using full stack. So presumably you will want the component to have access to the user too. You can do this via a server function:

[server(MagicNumber)]
async fn user() -> Result<u32, ServerFnError> {
    let Extension(user) = extract::<Extension<user>, _>().await?;
    Ok(user)
}

And the component can look something like:

[component]
fn DisplayUser() -> Element {
    let user = use_resource(user);

    rsx! {
        div {
            match &*user.read() {
                Some(Ok(user)) => {
                    rsx! {
                        p { "User: {u ser}" }
                    }
                }
                Some(Err(err)) => {
                    rsx! {
                        p { "Error loading your user: {err}." }
                    }
                }
                None => {
                    rsx! {
                        p { "Loading user..." }
                    }
                }
            }
            p { "Segments: {segments}" }
        }
    }
}

Disclaimer: Not tested but copied and pasted from code that was working :-).

However I just learnt you can use the extract function to retrieve axum extensions. I didn't know that. Cool!

[niclashoyer]

Thanks that helps a lot. Yes I'm using fullstack. I know how to set up an axum server manually and extend it with middleware, but I don't know how to integrate dioxus with axum and still be able to use dx serve. The launch method in the full stack server seems to do all the heavy lifting, but there seems to be no way to extend the router created here without replicating the whole code in my own main.

[niclashoyer]

I just discovered the middleware attribute which can be set on a server function. Maybe I'll give that a shot 👍🏽

[brianmay]

There is an example on setting up the axum router manually here: https://docs.rs/dioxus-fullstack/latest/dioxus_fullstack/

That middleware attribute looks interesting also.

[niclashoyer]

Thank you! That looks very promising. As soon as I have some authentication ready I'll come back with an example.

[brianmay]

I also have a demo app here: https://github.com/brianmay/dioxus-fs-demo

I plan to add postgres support and OIDC authentication support. Which I haven't got around to just yet (for a template that I can base my actual apps around).

But I use my custom commands to build (see build.sh and run.sh), I still haven't been able to get the "dx" command to work correctly. Probably my fault :-)

[brianmay]

I have found two issues with authentication:

First issue: current method is for the client front end to send a server request to ask what the user is. As in my example above.

Which is fine, but when the server generates the pre-rendered page, it has no idea what the user is. So we end up rendering the anonymous user page, and then switching after we get the response to the server request. Which is OK but not ideal.

Presumably(???) the solution would be to provide a function to the use_signal function that is able to work out what the user is on the server side.

But: As far as I am aware, this function supplied to use_signal is non-async only. And the extract() function is async (why?). So this isn't going to work out.

Second issue: Expiration of user sessions. e.g. if user logs out, it might be expected that all windows will stop showing sensitive information. Or if the session has timed out. Actually I haven't really thought much about this problem yet. But I think it s an important issue.

[ealmloff]

I have found two issues with authentication:

First issue: current method is for the client front end to send a server request to ask what the user is. As in my example above.

Which is fine, but when the server generates the pre-rendered page, it has no idea what the user is. So we end up rendering the anonymous user page, and then switching after we get the response to the server request. Which is OK but not ideal.

use_resource does not block server side rendering. If you are using fullstack, you can switch to use server future: let user = use_server_future(user)?;. That will block server rendering until the future is finished or if streaming is enabled just pause the current suspense boundary on the server until the future is finished

[brianmay]

Interesting. I missed that.

• I note that this returns a Result. Under what conditions does it return an error? Seems to have been missed from the docs.
• Trying to set a signal from a use_server_future results in a panic. Is this expected? If so, will investigate in more detail. Otherwise I won't worry. I got another solution for now.

[ealmloff]

• I note that this returns a Result. Under what conditions does it return an error? Seems to have been missed from the docs.

It returns a "Result" just so it can return early with ?. The error variant is returned when the future is pending and tells the component to suspend

• Trying to set a signal from a use_server_future results in a panic. Is this expected? If so, will investigate in more detail. Otherwise I won't worry. I got another solution for now.

use_server_future should not have any side effects like setting state inside of the future. Side effects cannot easily be serialized from the server to the client