Is there any objection for the store to control Id generation?

[jondot]

I've read the code and discussion, and it seems a repeating issue is around the Id.
It looks like this crate dictates the Id shape, form, entropy, while it might have been better to just give a loose sense of what Id should be.
This would enable those with more security requirements to enforce that, and also to implement stores such as cookie store (I'm aware of the recommendations and dis-recommendations for that)

so my question is, is there a hard principle here? maybe I can refactor the library to get a general form and sense of an Id? (e.g. just String)

[maxcountryman]

I'm open to it but it is a larger refactor.

My suggestion would be to move the implementation closer to actix session. (Please note, actix is fundamentally different and we'd need to be careful to not undo important aspects of this crate, like deferring session store loads).

A cookie store implementation should live in this crate behind a feature flag.

[jondot]

Just as a warning for myself is there anything else to consider than changing the type on the ID and then just going through the rabbit hole until I see the light?

[maxcountryman]

I think you're starting at the right place.

It would be nice if we could somehow express, via the type system, that certain properties of an ID should exist for properly secure cookies. I'm not really sure how to do that if we have a String. That may be okay but it does mean the crate is inherently less secure if we give up on a strongly typed ID.

Anyway besides the challenges of presenting an API that encourages or even enforces best practices around security, I don't think there are too many hidden hazards.