Elysia backend + Nextjs frontend, getSession issue

import { headers } from "next/headers";

import { authClient } from '@/lib/auth';

export default async function Home() {
const hdrs = await headers();
const sess = await authClient.getSession({
fetchOptions: {
headers: await headers(),
}
})
console.log("Session:", sess);

return (
<main className="flex min-h-[calc(100dvh-68px)] flex-col items-center ">
///
<pre>
{JSON.stringify(sess, null, 2)}
{JSON.stringify(hdrs, null, 2)}
</pre>
</main>
);
}
import { headers } from "next/headers";

import { authClient } from '@/lib/auth';

export default async function Home() {
const hdrs = await headers();
const sess = await authClient.getSession({
fetchOptions: {
headers: await headers(),
}
})
console.log("Session:", sess);

return (
<main className="flex min-h-[calc(100dvh-68px)] flex-col items-center ">
///
<pre>
{JSON.stringify(sess, null, 2)}
{JSON.stringify(hdrs, null, 2)}
</pre>
</main>
);
}
the getSession result is
{
"data": null,
"error": {
"status": 404,
"statusText": "Not Found"
}
}
{
"data": null,
"error": {
"status": 404,
"statusText": "Not Found"
}
}
even though the headers has a proper cookie after login my backend is elysiajs at port 3000 and frontend is nextjs at 3001. the other methods like, login and signup work (they're being called client side, not through server actions)
No description
4 Replies
sebastian
sebastian2w ago
i had something simmilar back ago, it was probably by using authClient on server-side i just created a endpoint that would get the session and i used this helper function
import { cookies } from "next/headers";
import { Session } from "./auth-client";

const getServerSession = async (): Promise<Session | null> => {
try {

const cookieHeader = (await cookies()).toString();

const res = await fetch(`${process.env.API_URL}/v1/session`, {
credentials: "include",
headers: {
Cookie: cookieHeader,
},
});

return res.json();

} catch (error) {
console.error(error);
return null;
}
};

export default getServerSession;
import { cookies } from "next/headers";
import { Session } from "./auth-client";

const getServerSession = async (): Promise<Session | null> => {
try {

const cookieHeader = (await cookies()).toString();

const res = await fetch(`${process.env.API_URL}/v1/session`, {
credentials: "include",
headers: {
Cookie: cookieHeader,
},
});

return res.json();

} catch (error) {
console.error(error);
return null;
}
};

export default getServerSession;
you can probably skip creating an endpoint and just fetch directly from /api/auth/get-session
ChestnutWaffle
ChestnutWaffleOP2w ago
so the authClient doesn't work on the server side? even while passing the right headers? @sebastian i've figured out why my api calls were not working from the server side of nextjs. it's because i was using a NEXT_PUBLIC prefix env variable. I don't know why it would be a problem to use a client env in server side instead of vice versa, but
export const authClient = createAuthClient({
baseURL: `${process.env.NEXT_PUBLIC_BACKEND_URL ?? "http://localhost:3000"}/auth/api`,
})

export const authServer = createAuthClient({
baseURL: `${process.env.BACKEND_URL ?? "http://localhost:3000"}/auth/api`,
})
export const authClient = createAuthClient({
baseURL: `${process.env.NEXT_PUBLIC_BACKEND_URL ?? "http://localhost:3000"}/auth/api`,
})

export const authServer = createAuthClient({
baseURL: `${process.env.BACKEND_URL ?? "http://localhost:3000"}/auth/api`,
})
doing this and using authServer at server side call works as expected probably didn't work because the whole backend+frontend is in a docker compose stack. and trying to fetch from port 3000 of localhost from inside a docker container wouldn't work because backend is in another container atleast I understand now why it didn't work
sebastian
sebastian2w ago
I'm glad you got it working. Honestly, maybe I'm being too skeptical, but I feel like using authClient on the server side seems like an authentication design flaw and a potential security risk. That's why I prefer to fetch on the server. Also according to this problem with envs, maybe because the vars with NEXT_PUBLIC prefix are meant to be only used in client components?
ChestnutWaffle
ChestnutWaffleOP2w ago
i don't think that's the case, it's the other way around, nextjs warns us when we use a non NEXT_PUBLIC prefix on the client side it's just that since my urls are localhost the nextjs app was checking within the container where nextjs was, but my backend is on another container i personally don't think there's any problem with using client code on the server, just the other way around like how it is with firebase admin, they advise against using that anywhere other that server side

Did you find this page helpful?