BA
Better Auth•2mo ago
dj

Server-side calls without request headers?

Hi, I was wondering if there’s a way to create users, send invitations, etc. purely from the server side, without having to pass through the request context or headers to the authClient.api.* functions. For example, is there a way to create an auth client that has a server secret token baked in or some other means of authentication that's baked into the client? Right now, if I want to build something like a generic user-invitation service, it feels awkward to either (a) not have the request handy, or (b) thread headers all the way down through multiple layers of my app just so I can call Better Auth in cases where, perhaps user invitations are sent as part of a larger complex workflow. What I’d really like is a way to make these kinds of trusted, server-initiated calls on behalf of the application itself (not tied to a logged-in user). Is there a supported way to do this in Better Auth?
4 Replies
Timo
Timo•2mo ago
Did you found a way?
LightTab2
LightTab2•2mo ago
How about creating a custom plugin with custom endpoint and calling auth.api.signInEmail?
Plugins | Better Auth
Learn how to use plugins with Better Auth.
The Untraceable
The Untraceable•2mo ago
Not sure if i 100% get what you mean. Using auth.api.foo calls the function, doesnt make an api request
dj
djOP•3w ago
here's my solution that I found: 
  // Mount Better Auth handler at the correct path
  app.on(["POST", "GET"], "/api/auth/*", async (c) => {
    const url = new URL(c.req.url)
    /* set the host header to the host of the request url so that better auth preserves the x-forwarded-proto
    * in better auth there is code that checks to see if both x-forwarded-proto and x-forwarded-host are set
    * and if so it uses them to construct the redirect url.
    * But AWS ALB's only set X-Forwarded-Proto, X-Forwarded-For and X-Forwarded-Port.
    * So we were seeing that the redirect url was being constructed with http:// instead of https://
    * See https://docs.aws.amazon.com/elasticloadbalancing/latest/application/x-forwarded-headers.html
    * So this is a workaround that we need in order to get the correct redirect url (https, not http)
    * see https://github.com/better-auth/better-auth/blob/2262198d515e3697e2cc7d205a5a5236d573ce9f/packages/better-auth/src/utils/url.ts#L43
    */
    c.req.raw.headers.set("x-forwarded-host", url.host);

    return await auth.handler(c.req.raw);
  });
  // Mount Better Auth handler at the correct path
  app.on(["POST", "GET"], "/api/auth/*", async (c) => {
    const url = new URL(c.req.url)
    /* set the host header to the host of the request url so that better auth preserves the x-forwarded-proto
    * in better auth there is code that checks to see if both x-forwarded-proto and x-forwarded-host are set
    * and if so it uses them to construct the redirect url.
    * But AWS ALB's only set X-Forwarded-Proto, X-Forwarded-For and X-Forwarded-Port.
    * So we were seeing that the redirect url was being constructed with http:// instead of https://
    * See https://docs.aws.amazon.com/elasticloadbalancing/latest/application/x-forwarded-headers.html
    * So this is a workaround that we need in order to get the correct redirect url (https, not http)
    * see https://github.com/better-auth/better-auth/blob/2262198d515e3697e2cc7d205a5a5236d573ce9f/packages/better-auth/src/utils/url.ts#L43
    */
    c.req.raw.headers.set("x-forwarded-host", url.host);

    return await auth.handler(c.req.raw);
  });

Did you find this page helpful?