Some types are not updated when combined with organization plugin

[manish-baghel]

Some organization plugin types are not inferred when used from within withCloudflare wrapper.
(Workaround 1 - without wrapper)
(Workaround 2 - with wrapper]

Configuration used:

return betterAuth({
        ...withCloudflare(
            {
                autoDetectIpAddress: true,
                geolocationTracking: true,
                cf: cf || {},
                postgres: {
                    db,
                    options: {
                        usePlural: true,
                        debugLogs: false,
                    },
                },
                kv: env?.KV as KVNamespace,
            },
            {
                plugins: [
                    admin(),
                    organization(),
                    apiKey(),
                    lastLoginMethod(),
                ],
            }
        )});

Logs:

➜ npm run build

> build
> npx tsc --noEmit

src/index.ts:100:25 - error TS2339: Property 'activeOrganizationId' does not exist on type '{ id: string; createdAt: Date; updatedAt: Date; userId: string; expiresAt: Date; token: string; ipAddress?: string | null | undefined; userAgent?: string | null | undefined; }'.

100     if (session.session.activeOrganizationId) {
                            ~~~~~~~~~~~~~~~~~~~~

src/index.ts:102:57 - error TS2339: Property 'getActiveMemberRole' does not exist on type 'InferAPI<{ ok: { <AsResponse extends boolean = false, ReturnHeaders extends boolean = false>(inputCtx_0?: ({ body?: undefined; } & { method?: "GET" | undefined; } & { query?: Record<string, any> | undefined; } & { params?: Record<string, any> | undefined; } & { ...; } & { ...; } & { ...; } & { ...; }) | undefined): ...'.

102             const { role: orgRoleStr } = await auth.api.getActiveMemberRole({ headers: reqHeaders });
                                                            ~~~~~~~~~~~~~~~~~~~

[manish-baghel]

The workaround is to not use withCloudflare wrapper and use cloudflare plugin directly

plugins: [
            cloudflare({
                autoDetectIpAddress: true,
                geolocationTracking: true,
                cf: cf || {},
            }),
            admin(),
            organization(),
            apiKey(),
            lastLoginMethod(),
        ],

You'll also need to configure KV manually and add ipAddress header config directly in better-auth options. Both these changes are pretty straightworward

{
// other config
  secondaryStorage: env?.KV ? createKVStorage(env.KV as KVNamespace) : undefined, // helper from better-auth-cloudflare
  advanced: {
            ipAddress: {
                ipAddressHeaders: ["cf-connecting-ip", "x-real-ip"],
            },
  },
}

Basically read through withCloudflare wrapper config and configure whatever is needed for your setup
https://github.com/zpg6/better-auth-cloudflare/blob/main/src/index.ts#L150-L224

[AlecDusheck]

Just ran into this. Removing withCloudflare and implementing the config manually seems to fix

[zpg6]

Hi @manish-baghel + @AlecDusheck ! Thanks for documenting this issue, I've run into it myself and haven't found an elegant solution but here's how you can keep using withCloudflare until we do:

// Singleton pattern to ensure a single auth instance
type ExplicitEndpoints = Awaited<ReturnType<typeof authBuilder>> & {
    api: ReturnType<typeof apiKey>["endpoints"] &
        ReturnType<typeof partPlugin>["endpoints"] &
        ReturnType<typeof searchPlugin>["endpoints"] &       // I made custom plugins for my site
        ReturnType<typeof trackingPlugin>["endpoints"] &
        ReturnType<typeof mcp>["endpoints"];
};
let authInstance: ExplicitEndpoints | null = null;

// Asynchronously initializes and retrieves the shared auth instance
export async function initAuth() {
    if (!authInstance) {
        authInstance = (await authBuilder()) as ExplicitEndpoints;
    }
    return authInstance;
}

[manish-baghel]

Thanks @zpg6 for sharing the alternate solution and also thanks for building this amazing plugin.

I was also thinking along the same lines but I realized I'll need to do this for session, api and any other types if I add a plugin which modifies these properties, so ended up choosing the manual way to configure.

Also from the DX standpoint, manual way(cloudflare plugin + other exported helpers) feels much simpler and cleaner. Honestly when I started to use the wrapper I got confused for a moment as I wasn't sure where to put other better-auth config

return betterAuth({
        ...withCloudflare(
            {
                autoDetectIpAddress: true,
                geolocationTracking: true,
                cf: cf || {},
                d1: env
                    ? {
                          db,
                          options: {
                              usePlural: true,
                              debugLogs: true,
                          },
                      }
                    : undefined,
                kv: env?.KV,
            },
            {
                emailAndPassword: {
                    enabled: true,
                },
                rateLimit: {
                    enabled: true,
                },
            },
           // Option 1 - can put other better-auth config here
        ),
        // Option 2 - can also put other config here
        // Only add database adapter for CLI schema generation
        ...(env
            ? {}
            : {
                  database: drizzleAdapter({} as D1Database, {
                      provider: "sqlite",
                      usePlural: true,
                      debugLogs: true,
                  }),
              }),
    });
}

Manual way
But with the manual way, it's way simpler and also the database config stays in one single place

function createAuth(env?: CloudflareBindings, cf?: IncomingRequestCfProperties) {
    return betterAuth({
        database: drizzleAdapter(
            env
                ? drizzle(
                      postgres(env?.HYPERDRIVE?.connectionString, {}),
                      {
                          schema: schema,
                          logger: true,
                      }
                  )
                : ({} as any), // necessary for cli schema generation
            {
                provider: "pg",
                transaction: true,
                usePlural: true,
                debugLogs: false,
            }
        ),
        secondaryStorage: env?.KV ? createKVStorage(env.KV as KVNamespace) : undefined, // helper from better-auth-cloudflare
        session: {
            storeSessionInDatabase: true, // needed for cloudflare plugin
        },
        plugins: [
            cloudflare({
                autoDetectIpAddress: true,
                geolocationTracking: true,
                cf: cf || {},
            }),
            organization(),
            apiKey(),
        ],
        emailAndPassword: {
            enabled: true,
        },
        advanced: {
            ipAddress: {
                ipAddressHeaders: ["cf-connecting-ip", "x-real-ip"], // ip-tracking cloudflare plugin
            },
        },
    });
}

[zpg6]

@manish-baghel thank you for great documentation of this and your feedback. There have been other questions about the configuration, perhaps I will remove the wrapper in next minor version update.

[AlecDusheck]

I'd agree with @manish-baghel and would probably have preferred just using the cloudflare plugin. The wrapper was confusing for me until I read into the docs. For instance, the wrapper maintains its own db object which overrides the betterAuth one.

[zpg6]

@AlecDusheck / @manish-baghel - my original thinking for the wrapper was to do the database/kv configuration for you.

Perhaps we can still provide the secondary storage interface and a helper so it's a one-liner for D1? Then configuring your own kv and d1 is simpler, or do you not even think this is needed?

[AlecDusheck]

Hmm, personally I'd learn towards just using the createKVStorage function. Would probably be good to still have the one-liner for people who want it? Not sure.

[zpg6]

I like the simplicity and type-safety we get.

And if the actual plugin surface area is smaller, this would also free the library up to work more on scripts that make for a nice workflow.

@AlecDusheck / @manish-baghel would be great to have your contribution on this if you would open a PR. I cannot get to it for a few days

For now let's deprecate the wrapper and point the docs and examples towards direct

[manish-baghel]

@zpg6
Thanks for sharing your thoughts.

Let me see if I can squeeze some time to create a PR. On the road rn ✈️ so please expect some delay