Asynchronous dbRecordIdFunction support

[TokugawaTakeshi]

Even CUID does not guarantee the full prevention of collisions, same about NanoID and UUID.
For the session ID, the collision is critical because if it will occur it will entail the leaking of personal and confidential data.

Thus after generating of ID, it is required to check the database table for duplication what is the asynchronous operation while dbRecordIdFunction does not support asynchronous generating.

Why not to leave to prisma-session-store the generating of ID?
Because it does not fit to the following approach.

• Use single method of IDs generating. (This principle will be violated if case by case omit the ID when adding the row to DB table or generate the ID before add the new row to table).
• Always validate does generated ID have preliminary defined fixed characters count
• Always check does generated ID already in use, and if, generate another ID.

[kleydon]

@TokugawaTakeshi thanks for this.

Thus after generating of ID, it is required to check the database table for duplication

In the prisma schema, id is required to be unique (it is defined as an @id) and sid is required to be unique (it is defined as @unique). I believe this means that Prisma prevents the possibility of duplication within in the database table...

Does that sound right?

[TokugawaTakeshi]

Thank you for the answer.

Does that sound right?

Sometimes.
But in some cases, the ID is being generated externally, for example during the data seeding.
Although the sessions are been rarely seeded, if you are sure that the ID should not be externally generated for sessions, why dbRecordIdFunction option is available?

[kleydon]

But in some cases, the ID is being generated externally, for example during the data seeding.

Interesting; I haven't thought extensively about this... (And I don't know very much about database-related workflows, so it is very likely that there are opportunities for improvements, here.)

Note: If you have access to the database, it is possible that you can create/edit ids in ways that are not controlled by this session store... For instance, in Prisma's "Studio" interface, you can edit session ids as free text (even enter a null string value!) So, even if efforts are made to tighten/restrict ID generation within prisma-session-store, we can't protect against scenarios that create/edit ids from outside the session store.

Although the sessions are been rarely seeded, if you are sure that the ID should not be externally generated for sessions, why dbRecordIdFunction option is available?

Trying to remember... I believe the idea was that we don't want to force a user to use cuid for session records; we want to allow for the possibility that a user might want to use another id function. (One motivation: I believe cuid has been depreciated in favor of cuid2).