Declarative auth guards for server functions

[rpfontana]

Hey! I've been working on a personal project with leptos and hit the auth wall that I think most people hit at some point: server fns don't do any access control out of the box (there's even a warning in the docs about it). Totally makes sense to keep the framework unopinionated on this, but I found myself copy-pasting the same auth check at the top of every server function and thought there might be a better way.

I know there's #[middleware] for wrapping server functions with Tower layers, and you can use it to provide context through extractors and handlers, so it's not as limited as I initially thought. But it still ties you to Axum specifically and doesn't work with Actix at all due to the async/sync mismatch in middleware traits (see #2436). I wanted something that works the same regardless of which backend you're running, so my approach runs the check inside the server function body instead of at the HTTP layer.

So I went down a rabbit hole and ended up designing what could become a small library around this. The core idea is a #[guard] proc macro that lets you do something like:

#[server(GetProfile)]
#[guard(Authenticated)]
async fn get_profile() -> Result<User, ServerFnError> {
    // this only runs if the user is authenticated
}

#[server(DeleteUser)]
#[guard(RequireRole(Role::Admin))]
async fn delete_user(id: i64) -> Result<(), ServerFnError> {
    // only admins get here
}

// works with strings too, not just enums
#[server(EditPost)]
#[guard(RequireRole("editor"))]
async fn edit_post(id: i64, content: String) -> Result<(), ServerFnError> { ... }

// and you can write your own guards for anything
#[server(InternalApi)]
#[guard(IpWhitelist(vec!["10.0.0.0/8".into()]))]
async fn internal_api() -> Result<String, ServerFnError> { ... }

The guard runs inside the server function (not as HTTP middleware), so it doesn't care whether you're on Axum or Actix. You just implement a Guard trait on whatever struct you want.

Then I kept going and added client-side pieces too, components like <Authenticated> and <RequireRole role="admin"> for conditional rendering, and hooks like is_authenticated() / has_role() that return Signal<Option<bool>> so they plug straight into leptos's <ProtectedRoute> condition prop.

The whole thing is meant to be unopinionated on the how: the library gives you the traits and the macro, you bring your own session/token/user logic.

Honestly I'm still pretty new to Leptos (and the Rust ecosystem in general), so I wanted to ask before building anything:

1. Is there already something like this that I'm not aware of? I looked around but couldn't find a good match.
2. Would it make sense as a standalone crate, or could parts of it fit into Leptos itself?

Any feedback is welcome (happy to be told this is a terrible idea too). Thanks!

[gbj]

Seems reasonable to me! It is a great example of something that can and should be implemented in a third-party library.