T3 Authentication (middleware vs client-side)
Multiple questions:
1. Is there a reason why T3 is set up with Database session authentication, which doesn't allow for middleware usage?
2. What are the benefits of using database sessions instead of JWT sessions?
-ie. You can see all users that are logged in and you can can terminate sessions on command if needed.
3. I asked a question on StackOverflow about how to protect certain page url routes and someone responded by saying to use middleware.
Are there any other ways to protect page url routes?
Ie:
Allow all-auth-users access to (but not public users access to): /account/userid
Allow only logged in session user access to: /account/userid/actions
Or is blocking access to page routes less of a concern since your API's will have server-side logic that protects any queries from going through.
11 Replies
T3 is supposed to give you a start with technologies so if you want to implement auth in a different manner you are able to do that. Also sessions are a nice and secure way to handle auth so thats one of the reasons why I assume it was setup in the way that it was.
Sessions are generally more secure overall than JWT and you can still remove a session from the data base with the sessions table
you are also able to use getServerSideProps to ensure that a user is auth and or logged in to protect your page very basic example is
export const getServerSideProps: GetServerSideProps = async (ctx: GetServerSidePropsContext) => {
const session = await getServerAuthSession(ctx);
if (!session) {
return {
redirect: {
destination: "/",
permanent: false
}
}
}
return {
props: {}
}
}
This will return the user to sign in page if they are not logged in
you may add additional logic here to check if they are able to do what they are trying to do
Hopefully I understood what you are asking and was able to provide help 👍
A tradeoff for using Sessions vs JWT is that you're forced to use getServerSideProps to protect your pages since as you said, you cannot use session tokens in middleware right now. This might be undesired depending on your usecase
I did not know that trade off existed
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
oh because I vaguly remembered doing it that way once
Sorry I misstyped it. I meant you're forced to call your backend client-side
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
^
Yeah I agree. Database sessions are my preferred choice as well. Just sad we can't use them in middleware, but maybe eventually ;p
I dont like JWTs
mainly because theo said so
^this is a joke btw
Re: 3 - you could also do it in the handler itself. But why? Protecting a route server side is the same each time. Ultimately you need to run some code that checks whether the user is authed at some point between the server starting to handle the request, and the server sending a response. Ideally before the server ever gets any critical data from db.