-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
[FEATURE] Move premium user check to middleware #9630
Comments
To reduce notifications, issues are locked until they are
🏁 status: ready for dev
|
The issue has been unlocked and is now ready for dev. If you would like to work on this issue, you can comment to have it assigned to you. You can learn more in our contributing guide https://github.com/EddieHubCommunity/BioDrop/blob/main/CONTRIBUTING.md |
This will clean up the code. I am not sure how possible it is to get the session in the middleware to do the check though - so we might have some challenges ℹ️ eddiejaoude has some opened assigned issues: 🔧View assigned issues |
Upon investigation there are 3 different path forward that have been investigated so far. Each of them having there own pros and cons. Next.js "middleware.js" runs into a separate light weight runtime environment called Edge. "The Edge Runtime offers lower latency, higher scalability, and better security than Node.js, but it has some limitations, such as not supporting native Node.js APIs." There is an ongoing discussion for middleware.js to allow Node.js runtime: |
Proposal 1 Adding accountType on the JWT Token pages/api/[...next-auth].js
middleware.js We use the
|
The advantage of this solution is that it leverages existing code (next-auth), but a drawback is that we would need to reset the JWT Secret, resulting in the logout of all users. |
Solution 2 As a work around to being unable to make MongoDB calls from the middleware.js file: middleware.js Make a request to Next.js API end point and include in the header an authenticated cookie(required by next-auth).:
pages/api/getSession.js
CON: Making an API and database requests could be an additional resource burden. |
Thank you for the different solutions, I will go through in more details tomorrow. Please note: we have the session and the mongodb connection in the middleware already here... Lines 31 to 34 in b11b991
|
But according to the next auth documentation: https://next-auth.js.org/tutorials/securing-pages-and-api-routes#using-gettoken getToken function is being used to get jwt token information, which doesn't contains accountType property |
We add this to the session here BioDrop/pages/api/auth/[...nextauth].js Line 74 in b257fc2
|
You right, but there is a difference between session and jwt token, session is being stored in the database (to which we don't have access due to edge runtime), and jwt is being stored in user cookie, here an example of what jwt actually looks like: const session = await getToken({
req: req,
secret: process.env.NEXTAUTH_SECRET,
});
console.log(session)
/*
{
name: 'Dmitry Kulakov',
email: 'atomeistee@gmail.com',
picture: 'https://avatars.githubusercontent.com/u/36533957?v=4',
sub: '6542306a8e45c14d99cb27ea',
accessToken: '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',
id: 36533957,
username: 'dmitrykulakovfrontend',
iat: 1699335414,
exp: 1701927414,
jti: '74aa1844-6e30-403e-bab7-d7e611884d20'
}
*/ This is the reason why we were suggesting Solution #1, which would basically do the same thing like session.accountType = user.type; but with jwt token instead. But because that would create a difference between users with new jwt tokens and old we would need to sign out everyone and make sure that everyone has same jwt, by changing the JWT Secret. I think it is some kind of missunderstanding naming result of getToken as session |
Oh I see, now I think I understand better, thank you for explaining 👍 ℹ️ eddiejaoude has some opened assigned issues: 🔧View assigned issues |
The current naming convention is confusing and it will be remedied in the solution we propose. (session is actually JWT token). const session = await getToken({
req: req,
secret: process.env.NEXTAUTH_SECRET,
});
// if no session reject request
if (!session) {
if (reqPathName.startsWith("/api")) {
return NextResponse.json({}, { status: 401 });
}
return NextResponse.redirect(new URL("/auth/signin", req.url));
} session should be renamed to something resembling JWT Token. |
Pull Request merged, great collaboration |
Is this a unique feature?
Is your feature request related to a problem/unavailable functionality? Please describe.
For /pages/account/statistics we are using "getServerSideProps" redirection instead of using middleware.js. The middleware ends code duplication and reduces possibility of introducing errors.
Proposed Solution
I'm proposing we consolidate authentication checking using only middleware.js.
Screenshots
Do you want to work on this issue?
Yes
If you want to work on this issue...
I would add in middleware.js a code that would look at current user route and if it is /account/statistics and user account type is not premium, it would redirect him
The text was updated successfully, but these errors were encountered: