Feat/admin auth

[conradangwz]

📑 Description

Added admin role to the DB and updated the auth to accommodate it. Tested on the home page, and it is working as intended.
Pushed the auth consumption down to the components. The image component now does that admin check itself, hence the image block component no longer requires a passed prop.
Added the admin route guards for necessary routes. Currently, POST, PUT, and DELETE requests are protected, while GET requests are available to the public. I tested it in Postman, and it is working. Created a similar guard for the frontend, where if they try to access a page that is only for admins, the user gets blocked; however do not know how useful this will be as we are building the admin functions on top of the preexisting user pages, but in future, it could be useful

✏️ Summary of Changes

• AuthProvider.tsx — added admin: "admin" | "user" to GoogleUser interface
• AuthContext.tsx — added admin to AuthContextType and context default
• authRoutes.ts — /me endpoint now pulls admin from MongoDB and attaches it to the response
• ImageBlock.tsx — removed role prop, now reads admin directly from useAuth()
• imageRoutes.ts — POST / protected with requireAdmin middleware
• executivesRoutes.ts — POST, PUT, DELETE protected with requireAdmin middleware
• AdminRoute.tsx — new frontend route guard, redirects non-admins to /
• adminGuard.ts — new backend middleware, returns 401 if unauthenticated, 403 if not admin
• Updated axios to version 1.16.0

📸 Screenshots

No video - the visible change is the appearance of the edit button on images when logged in as an admin.

Cookie connect sid of a user

Cookie connect sid of admin

Unauthenticated user trying to access routes

✅ Ready?

• Added documentation/updated README to reflect changes (if necessary)
• Added in-code documentation (wherever needed)
• Wrote tests for new components/features
• Branch and PR title adheres to naming conventions
• Self-reviewed PR

[RLee64]

Nice work! Great to see it working.

Thinking about this a bit more, could we change this to make frontend hold a 'role' with type
"guest" | "user" | "member" | "admin"
Guest - someone who's not signed in
Member - someone who's signed in, is not an admin, and has paid for the year
Legacy - someone who's signed in, is not an admin, and has not paid for the year
Admin - someone who's signed in and is an admin

Ignore the Legacy role for now and assume all non-admin signed in users are members.

I think backend should should also hold information a bit differently. What we'll want instead is a boolean attribute rather than a string for determining whether a user is an admin. This defaults to being false. Later we'll add a field like hasPaid to distinguish between member and legacy users. These attributes are then used in combination to determine the user role assigned at frontend.