Question regarding the use of crypto.js as the userId #117
BiscuiTech
started this conversation in
General
Replies: 1 comment 7 replies
-
To be honest, the reason Lucia generates its own user id was because UUIDs are too long (of course that's different now). I'm not really sure on this one. I guess I can make custom id generation optional, so Lucia will pass on an empty user id to the adapter? We'd still have the crypto dependency since it's used for hashing passwords btw. For now, if you need something that conforms with UUID/CUID, you can use |
Beta Was this translation helpful? Give feedback.
7 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi! Let me preface this by saying that I really love this package. The solution is quite elegant and fluid. It's honestly a breeze to implement it in a sveltekit app.
I had a question regarding the internal mechanics of the auth.
I'll jump right ahead: why did you make the Auth class generate the userId itself instead of letting database adapters manage it? Wouldn't the adapter be the best place to handle these sorts of implementation? Right now, a prisma schema such as this:
wouldn't work since the
cuid
isn't conform with thecrypto.js
-based userId provided in the setUser functions of the adapters. As I understand it, the reason here is that you need the userId to create the refreshToken before creating the user, but wouldn't it better if we had some sort of transaction implemention of all-or-nothing with multiple creates and updates? Or better yet, simply create the user and then create the refreshToken, letting you drop this crypto.js dependancy and let the adapter manage the ID generation.Beta Was this translation helpful? Give feedback.
All reactions