-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ID spoofing #7
Comments
Hi Rob, I don't see a problem with enforcing sequential IDs if you have a need for them in the context of your application. Ensuring that IDs are sequential is not the same thing as decoding the groupings to extract any semantic meaning from the ids. For example, I would consider it unwise to extract the datestamp and use it as the entity creation time in your application, or to extract the client sequence and use it for some semantic purpose in your application. I think that enforcing sequence is in a different class. That said, clients that are not under your control could spit any random timestamp at you. It's up to you to determine how you'll handle those cases. I'd be careful not to be too strict. There are other ways to optimize database performance. For instance, you could insert a memory cache such as Redis or Memcached in front of your permanent storage. I'm a strong believer that these sorts of performance optimizations shouldn't be too coupled to your application logic. |
Thanks for the feedback. I will probably just settle on doing some basic format (sanity) checking on the id and leave it that. Rob |
👍 |
Hi,
Was wondering what your thoughts were on the potential of spoofed Id's originating from untrusted clients.
One of the things that appeals to me about cuids are the fact that id's are more or less sequential (assuming consistent time sources), which means I can use them as PK's in my DB and won't get burnt on inserts (due to the rows being stored.as a clustered index),
This does however leave an unsavory taste in my mouth - as an untrusted client could screw with my DB index by generating unique, but non sequential id's.
I was thinking of performing some sanity checking server side on any new id's generated client side. Nothing too restrictive, I would probably just check the basic format is correct and that the timestamp fits within a suitably large window. I then noticed this in the README:
"The cuid specification should not be considered an API contract. Code that relies on the groupings as laid out here should be considered brittle and not be used in production."
Do you believe this applies in the stated context?
Regards
Rob
The text was updated successfully, but these errors were encountered: