feat(next-auth): add getServerAuthSession

[henriqgoncalvs]

Add getServerAuthSession helper and a Protected route using it

✅ CHECKS

• [ x ] I reviewed linter warnings + errors, resolved formatting, types and other issues related to my work
• [ x ] The PR title follows the convention we established conventional-commit
• [ x ] I performed a functional test on my final commit

---

📝 CHANGELOG

• I've created a function that abstracts the use of unstable_getServerSession from next-auth.
• To serve as an example how this function will going to be used, i've create a Protected route as well

💯

[juliusmarminge]

Would you mind making the same change to next?

[juliusmarminge]

Great! Would be good with some refactoring to take advantage of this wrapper in the other places too:

create-t3-app/template/addons/trpc/auth-context.ts

Lines 14 to 15 in 9392374

	const session =
	req && res && (await getServerSession(req, res, nextAuthOptions));

create-t3-app/template/addons/trpc/auth-prisma-context.ts

Lines 15 to 16 in 9392374

	const session =
	req && res && (await getServerSession(req, res, nextAuthOptions));

create-t3-app/template/addons/next-auth/restricted.ts

Line 8 in 9392374

const session = await getServerSession(req, res, nextAuthOptions);

[juliusmarminge]

@theobr Just to make sure, are we stepping on any toes when we disregarded protected routes in #122 (I think the main issue there was the JWT story)?

[henriqgoncalvs]

Would you mind making the same change to next?

You mean the restricted route without tRPC?

https://github.com/t3-oss/create-t3-app/blob/main/template/addons/next-auth/restricted.ts

[juliusmarminge]

Would you mind making the same change to next?

You mean the restricted route without tRPC?

https://github.com/t3-oss/create-t3-app/blob/main/template/addons/next-auth/restricted.ts

I mean submitting the PR to the Next branch as well. Otherwise I'll do it after no problem

[henriqgoncalvs]

Would you mind making the same change to next?

You mean the restricted route without tRPC?
https://github.com/t3-oss/create-t3-app/blob/main/template/addons/next-auth/restricted.ts

I mean submitting the PR to the Next branch as well. Otherwise I'll do it after no problem

Oh, okay! I will wait for this branch to be 100% ready to merge and will open another PR for the next branch

[t3dotgg]

Concerned this is a lot of changes for a feature I don't see as super useful (and quite prescriptive). Many users might prefer to render a sign-in component on a "protected route" instead. The as bindings also scare me a bit as they weren't necessary before 🤔

Not hard stanced either way just some thoughts

[henriqgoncalvs]

Concerned this is a lot of changes for a feature I don't see as super useful (and quite prescriptive). Many users might prefer to render a sign-in component on a "protected route" instead. The as bindings also scare me a bit as they weren't necessary before 🤔

Not hard stanced either way just some thoughts

I think you got a point there about the sign-in component, but I think most users will find an example for a basic protected route with SSR very helpful as a starting point. also, we're not inferring any return of the session or how you should use it.

about the inferring, yeah I also didn't like it when I committed haha I preferred to wait for your opinions on it. I needed to put it because the opts argument is optional (even tho looking at the types I think it's not, you always receive the req and res object from the createNextApiHandler, but I'm not so sure about this).

for short, I do think it's better if we just use the helper in the protected page and the restricted route, what do you guys think?

[juliusmarminge]

Not hard stanced either way just some thoughts

Yea I am good either way. It isn't a big deal to make myself when I end up needing it, but it is a nice to have to only import a single thing and not passing the nextAuthOptions around everywhere.

opts argument is optional

Yea from what I can tell we should be good removing the optional here. This is the underlying typedef:

export type NodeHTTPCreateContextFnOptions<TRequest, TResponse> = {
  req: TRequest;
  res: TResponse;
};
export type NodeHTTPCreateContextFn<
  TRouter extends AnyRouter,
  TRequest,
  TResponse,
> = (
  opts: NodeHTTPCreateContextFnOptions<TRequest, TResponse>,
) => inferRouterContext<TRouter> | Promise<inferRouterContext<TRouter>>;

What are your thoughts on this @nexxeln

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
create-t3-app	✅ Ready (Inspect)	Visit Preview	Aug 18, 2022 at 3:55AM (UTC)

[henriqgoncalvs]

sorry for sitting on this for so long, made the updates removing the type inferring on de arguments of getServerAuthSession.

also updated the README with a link to the protected page example. one thing I caught up on was that I couldn't access the session object as props in SSR pages, so I also removed that guide in the protected page and recommended accessing with the useSession hook as you would normally do.

[Fedeorlandau]

Hi there!

First, thank you for your contribution.

I think this is too opinionated for create-t3-app. This protected page is using getServerSideProps which is not always what people want. You may want to protect your routes (for whatever reason) on the client side without having to involve a server call at all. Next/auth provides a lot of examples for doing this through middleware or even server-side on their official docs.

Just saying that it can be misleading.

EDIT: And next-auth session management breaks on every next.js release. We shouldn't trust it enough to put it that much on a cli.

Cheers,

[juliusmarminge]

Hi there!

First, thank you for your contribution.

I think this is too opinionated for create-t3-app. This protected page is using getServerSideProps which is not always what people want. You may want to protect your routes (for whatever reason) on the client side without having to involve a server call at all. Next/auth provides a lot of examples for doing this through middleware or even server-side on their official docs.

Just saying that it can be misleading.

EDIT: And next-auth session management breaks on every next.js release. We shouldn't trust it enough to put it that much on a cli.

Cheers,

Seems fair. We declined protected routes before so maybe we should be careful now too.

Perhaps only use it to get the auth session in the example api endpoint as well as the tRPC context then.

[juliusmarminge]

Moved to #366