Add account creation to Vortex #912
Conversation
✅ Deploy Preview for vortexfi ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for vortex-sandbox ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
… AUTH_SUCCESS handling
…ility and user experience
Address code review comments: security, performance, and bug fixes
| }); | ||
| } | ||
|
|
||
| await SupabaseAuthService.sendOTP(email); |
There was a problem hiding this comment.
I believe this operation is stateless on the backend, right? Maybe we could add an entry to the users table, to mark the last OTP timestamp or any other metadata.
In case we loose the state in the UI or we want to keep track.
| // Sync user to local database (upsert) | ||
| await User.upsert({ | ||
| email: email, | ||
| id: result.user_id |
There was a problem hiding this comment.
Is the upsert only for handling new users? I assume the userId should never change but I may be wrong.
gianfra-t
left a comment
gianfra-t
left a comment
There was a problem hiding this comment.
Very nice and complete feature, thanks @ebma ! The only thing I would like to discuss is what you think about changing the token into the cookies and avoid storing it in the local storage.
I understand there is a tradeoff in terms of security between both methods.
| }), | ||
| ({ event, context }) => { | ||
| // Store tokens in localStorage for session persistence | ||
| AuthService.storeTokens({ |
There was a problem hiding this comment.
I also wanted to discuss the pros/cons of using localStorage vs cookies (httpOnly) for the tokens.
I believe our application already handles httpOnly cookiens for the SIWE login, so we have an example, which seems to be the preferred way for browser apps.
Do you see this solution better in terms of security, for our case?
There was a problem hiding this comment.
You have a fair point, thanks for raising this. I think for the time being, the localStorage approach is fine and not that big of a risk. Doing this with cookies seems to be more cumbersome and also restricts in the future if we ever decide to make the Vortex widget embeddable. Not sure when or if that's ever gonna happen but I'm a little scared of changing this now, introducing extra complexity just making our developer experience worse. If you have strong opinions on this, I would be open to consider it though.
There was a problem hiding this comment.
I didn't think about the possibility of embedding the site, sure.
Let's then check if there is anything we can add to mitigate those risks? With this local storage solution.
But I'm fine if we do it later.
| type: DataTypes.UUID | ||
| }); | ||
|
|
||
| await queryInterface.sequelize.query(` |
There was a problem hiding this comment.
Can we keep the userId relation for this one (and any that allows for null) empty instead of using the dummy? Or do you think there is a benefit of using the dummy user here?
There was a problem hiding this comment.
Hmm, well maybe we should just allow it to be null on each table. You are right that the dummy user is not great. I used it so we can enforce the non-null constraint that is logical on some of the tables but now that I think of it, it might be better if it can be null and we just add it later..
There was a problem hiding this comment.
Yes I dont have a strong opinion on either as they both serve the same purpose. null seems a bit easier to deal with after than the dummy.
Oh but if I remember correctly, those fields allow for a null relationship so no need to change that constraint itself.
There was a problem hiding this comment.
Maybe to also make the migration easier to follow. Not much more
There was a problem hiding this comment.
Some of them did, some didn't. But I adjusted it so that the userId is nullable on all the other relations and the code checks if necessary.
…for optional authentication
|
@ebma Please let me know when it's ready for review again 🙏 |
|
@Sharqiewicz I consider the changes ready now :) |
|
@ebma Ok, thanks. I'll review it today |
Closes #882.
This pull request introduces Supabase-based authentication to the API, including OTP (one-time password) flows, token verification, and user session management. It adds new authentication endpoints, middleware for extracting and verifying user identity from requests, and propagates the authenticated
userIdthroughout the business logic and data models. Several routes now optionally or mandatorily require authentication, and the system is prepared for future endpoint protection. Additionally, the codebase is updated to store and utilize theuserIdin key models and service layers.Supabase Authentication Integration
.env.exampleand included@supabase/supabase-jsas a dependency inpackage.json. [1] [2]SupabaseAuthServicewith methods for checking user existence, sending and verifying OTPs, verifying and refreshing tokens, and retrieving user profiles. [1] [2]AuthControllerwith endpoints for checking email registration, requesting OTP, verifying OTP, refreshing tokens, and verifying tokens. [1] [2]/v1/authroutes for authentication endpoints and registered them in the main API router. [1] [2] [3]Authentication Middleware and Route Protection
requireAuthandoptionalAuthmiddleware to extract and verify user identity from Bearer tokens, attachinguserIdto the request.optionalAuthmiddleware, allowing endpoints to accessuserIdif provided. [1] [2] [3] [4] [5] [6] [7]User Identity Propagation
brla.controller.ts,quote.controller.ts,ramp.controller.ts) to storeuserIdfrom the request in database records and service calls. [1] [2] [3] [4] [5] [6]userIdas part of the request context and data models. [1] [2]These changes collectively enable secure, user-specific flows across the API, laying the groundwork for robust authentication and authorization using Supabase.