You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Came across Clerk yesterday, and hugely impressed. We are doing a POC to asses it as a possible Auth0 replacement.
However, it is hard to get your head around this backendless flow, specifically once one is accustomed to Auth0 universal login flow (which is backend centred).
I keep on wishing there was an edge-runtime API to make all the calls to Clerk, instead of doing all from the frontend (and I have read the rationale behind the current design in this answer by @SokratisVidros). A quick look at core/resources suggests most of the code is backend compatible.
The frontend nature of Clerk is relevant to the case below.
I'm trying to figure out how to do what I believe is the (rather common) use case below.
Context
NextJS
Vercel Deployment
Ideally all that can should live on the edge
Passwordless Email OTP only
Using custom flow: useSignUp & useSignIn
Use case
Our database is designed so each new user gets an auto-increment id, which is then used as a key in various relationships; (had we used the sub auth-provider user id for relationships, this problem would not have existed).
User signs up.
Once successful, the user is added to the app DB, with its email saved and an allocated auto-increment id (integer - dbId).
We want that dbId in the session cookie, so with every API request we know it, rather than having to ask the DB - "What is the user id for this user email (or auth provider user id)".
Same for sign ins - we want the session cookie to include dbId.
Also, it is worth mentioning that the possibility to log in users without them navigating away from the page is hugely attractive to us - a flow involving redirects (like Auth0 universal login) does not allow this.
Possible Solution 01
The user clicks Submit Email;
The front end sends a request to the backend with the user email;
concern: This is a public non-authenticated API which create users.
A new record created on the app DB;
The dbId is returned to the frontend;
The dbId is given to signUp.create({ emailAddress, unsafeMetadata : { dbId }})
(The session token is customised to include {{user.unsafe_metadata}})
In theory, at this point we have all that is needed in place:
The user email and dbId in the db.
That dbId in the session cookies (forever, as it is part of unsafe_metadata)
A further improvement would be to create a webhook back to the app that notifies it a user has been created - this way the app can tell that user has completed signup (so it can purge incomplete sign-ups, and not send the user any communications via email).
Am I missing anything? Are there any other options?
Possible Solution 02
Not create a db user before signup is done.
Not pass the dbId as unsafe_metadata to signUp.create.
Rather, at middleware.ts level, check if session cookie has dbId
If not, create the user on the DB, and use the Clerk Backend API to add unsafe_metadata (or public_metadata)
Not sure how with this solution you can ask to "refresh" the session cookie (so it includes the metadata and hence the dbId) - this is to prevent that user initiating the "if not" case above until they login again.
How does it work with Auth0 universal login?
You do not to store these as custom claims.
Rather, one can hook on the callback and modify the session there:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Came across Clerk yesterday, and hugely impressed. We are doing a POC to asses it as a possible Auth0 replacement.
However, it is hard to get your head around this backendless flow, specifically once one is accustomed to Auth0 universal login flow (which is backend centred).
I keep on wishing there was an edge-runtime API to make all the calls to Clerk, instead of doing all from the frontend (and I have read the rationale behind the current design in this answer by @SokratisVidros). A quick look at core/resources suggests most of the code is backend compatible.
The frontend nature of Clerk is relevant to the case below.
I'm trying to figure out how to do what I believe is the (rather common) use case below.
Context
useSignUp
&useSignIn
Use case
Our database is designed so each new user gets an auto-increment id, which is then used as a key in various relationships; (had we used the
sub
auth-provider user id for relationships, this problem would not have existed).dbId
).dbId
in the session cookie, so with every API request we know it, rather than having to ask the DB - "What is the user id for this user email (or auth provider user id)".dbId
.The solutions described in Sync data to your backend are not exactly what's needed here.
Also, it is worth mentioning that the possibility to log in users without them navigating away from the page is hugely attractive to us - a flow involving redirects (like Auth0 universal login) does not allow this.
Possible Solution 01
dbId
is returned to the frontend;dbId
is given tosignUp.create({ emailAddress, unsafeMetadata : { dbId }})
{{user.unsafe_metadata}}
)In theory, at this point we have all that is needed in place:
dbId
in the db.dbId
in the session cookies (forever, as it is part ofunsafe_metadata
)A further improvement would be to create a webhook back to the app that notifies it a user has been created - this way the app can tell that user has completed signup (so it can purge incomplete sign-ups, and not send the user any communications via email).
Am I missing anything? Are there any other options?
Possible Solution 02
dbId
asunsafe_metadata
tosignUp.create
.middleware.ts
level, check if session cookie hasdbId
unsafe_metadata
(orpublic_metadata
)Not sure how with this solution you can ask to "refresh" the session cookie (so it includes the metadata and hence the
dbId
) - this is to prevent that user initiating the "if not" case above until they login again.How does it work with Auth0 universal login?
You do not to store these as custom claims.
Rather, one can hook on the callback and modify the session there:
Beta Was this translation helpful? Give feedback.
All reactions