Expose Validators from BetterAuth Tables

[RetroThorium]

Hi,

Thank you so much for the amazing work. I was wondering if this component provides validators to be used from the main app. For example , if I have a mutation that takes in user id .. would it be possible to validate against that or v.string() is the only alternative.

Consider an example:

export const addResource = mutation({
    args: {
        title: v.string(),
        ownerId:  v.id("user") // <--- this doesn't work as user table is inside betterauth component 
    },
    handler: async (ctx, { title,  ownerId }) => {
        // Insert resource
    },
});

If there are no validators, is there a plan to expose them?

Thanks again!

[erquhart]

If you're not using local install, you generally want to lean on the typed api's provided explicitly by the component or Better Auth itself. With local install you have control of the component schema so it makes sense to reuse those types in that case. For the id type, there's no way to get a runtime and at-rest validated id type across the component boundary. Looking at providing a branded validator so there's at least type safety even if not at runtime.

[hdoro]

@erquhart thank you for the work on this component!

From what I gather from your comment, then, I can't really do v.id('users') (or 'betterAuth.users') in my schema as components are isolated and inaccessible from my own schema, right? So the second best would be to do:

const vUserId = v.string() as VString<UserId, 'required'>

const myPostSchema = v.object({ author: vUserId, /* ... */ })

This to me doesn't feel great, I'd much rather have some sort of referential integrity, and proper validators in arguments... Is there any workaround? For example, can I install betterAuth as a part of my schema instead of as a component, similar to how Convex Auth does it? I know I could adapt the code and keep a copy of it in my directories... but that feels brittle and more work than ideal.

I was thinking of sticking to Convex Auth, but since the underlying Auth.js is in the process of being absorbed by Better Auth, it doesn't make sense to bet on it for a new project (or does it?)

[RetroThorium]

Thanks for the clarification @erquhart. We are using the local install to develop our auth system.

However, I agree with @hdoro that workarounds and/or branded types may not be enough. The general guidelines of convex queries and mutation suggests that authorization should be handled inside these procedures. This makes accessing the betterAuth tables a must.

What we have managed so far is to never accept component tables as arguments.
The user ( and other betterAuth tables) are always accessed via server side api.

So for example

export const addResource = mutation({
    args: {
        title: v.string(),
    },
    handler: async (ctx, { title,  ownerId }) => {
          const session = await createAuth(ctx).api.getSession({ headers: headers });
          const ownerId = session.user.id // <--- this works. Not sure about the pitfalls / race conditions
          // Insert resource
    },
});

This has the added advantage that no argument validation is required and no values are transferred, reducing the attack surface (at the very least MiTM). However, I am not sure if that's the correct way to handle authz.

I also like the @hdoro's idea of just having all these tables in the app schema itself. (@hdoro Thanks btw!)
Gives you a lot of flexibility and control. Maybe with the growing number of supported plugins, that might be the easiest solution after all.

[erquhart]

Component architecture is important for a number of reasons, so this component will likely continue to double down on that. There are definitely improvements to make to components, that's understood.

I can only see one issue being called in the above comments, and it's around losing validation of table ids when using components. The recommendation here is to track your own users table and use the id from that user record everywhere, as it does have the id type validation you're looking for.

@RetroThorium in your example, the resulting id is still of string type, and overall what you've done is reimplement authComponent.getAuthUser(), without any differences in process or outcome. Can you help me understand what you're after?