4 ms·

Hi, I'm mister UUID and I have been living in your favourite framework since 2001. Use me.

megaman22 8y ago
Holy schmolies, yes. And if you use them as your access keys for, say, a webservice, people aren't really going to be able to fish around the same way they can if you use auto-increment integers. If your url looks like https://awesomeunicorn.com/userProfile/123 https://awesomeunicorn.com/userProfile/123, it's pretty obvious that I could start poking around and trying to get user 122 or 124. If that url is https://awesomeunicorn.com/userProfile/123456-dead-beef-abba-0123456789ab https://awesomeunicorn.com/userProfile/123456-dead-beef-abba..., I don't really have any idea what the ID of the next user might be.
- pletnes 8y ago
  The downside is that your urls are long, ugly and incomprehensible.
  - zxcmx 8y ago
    The upside is that your business is not totally transparent to outsiders who can figure out how many users, carts, products and messages you are adding each month.
    - pletnes 8y ago
      There must be some other way. I can often figure out the direct url to a software project in bitbucket, but office365 urls are pages long. I somehow doubt atlassian is as transparent as you say. Disclaimer: not a web dev
- llao 8y ago
  If trying more or less random URLs of your service is an issue for you, you have an issue.
  - megaman22 8y ago
    True, you absolutely should have security and authorization setup. But if the server replies to the request with a 401 or 403, rather than a 404, you at least know that there is something there.
- kuschku 8y ago
  This is a massive issue with pastes on GitLab. Unlisted, private, public snippets all get links such as https://gitlab.com/snippets/1712835 https://gitlab.com/snippets/1712835 If you have an instance with few users, you can just create a new snippet and then auto-decrement. e.g. I just found https://gitlab.com/snippets/17128 https://gitlab.com/snippets/17128 this way.
drawkbox 8y ago
UUID are the way, GUID for those in Microsoft's lands. Not only will you never run out but you don't need a round trip to the keymaster, horizontal scaling, clustering and vertical sharding even are all way easier due to that. This removes a single point of failure entirely when the keymaster is no longer needed. Using ints for keys for profiles/users and many other things were needed way back when processing/db/disk/memory and performance from that were a problem, no longer. Do your part, join the UUID revolution. Also, if you were a piece of data, would you not want to be unique across all the databases, storage and services? You've heard of Roko's Basilisk right? Do not disappoint.
- kasey_junk 8y ago
  I’ve often wondered where the tipping point is where you do start having to worry about collisions. Is frantic “fix all the uuid breaking code” the jobs boost for programmers 20 years from now? 100? It seems unthinkable now but who knows...
  - drawkbox 8y ago
    We'll be good until at least sentient AI takes over and they can solve it for us, or them.
- sethammons 8y ago
  We've had multiple collisions with uuid v4. I'm not overly familiar with the examples, but in one case, the collision was found because the collision happened in the same account! Customer: "Why do these two events have the same id?" Us: "Wow." I think we determined that it was a limitation in the random number generator in the Perl lib we were using. To avoid that, I believe the solution was to go with uuid v1 plus a nonce of some sort.
  - cesarb 8y ago
    If you have collisions with UUID v4, something is really broken with your UUID generator. It's not a "limitation", it's a critical bug.
edejong 8y ago
Other advantages of UUIDs: - client can generate the UUID, allowing eventual consistency and retrying using distributed DBs (other DB is on phone for example) - merging of DBs is easy - allows capability based access control (you can’t guess the UUID, you don’t have access) - can use a bit or teo to encode production vs development IDs, so cross contamination of systems is less likely
deleted 8y ago
[deleted]
malingo 8y ago
This post discusses using UUIDs as primary keys (but never exposing them), and an additional integer key on each table as the public facing ID. https://begriffs.com/posts/2018-01-01-sql-keys-in-depth.html https://begriffs.com/posts/2018-01-01-sql-keys-in-depth.html HN discussion: https://news.ycombinator.com/item?id=16050047 https://news.ycombinator.com/item?id=16050047

Holy schmolies, yes. And if you use them as your access keys for, say, a webservice, people aren't really going to be able to fish around the same way they can if you use auto-increment integers. If your url looks like https://awesomeunicorn.com/userProfile/123 https://awesomeunicorn.com/userProfile/123, it's pretty obvious that I could start poking around and trying to get user 122 or 124. If that url is https://awesomeunicorn.com/userProfile/123456-dead-beef-abba-0123456789ab https://awesomeunicorn.com/userProfile/123456-dead-beef-abba..., I don't really have any idea what the ID of the next user might be.

pletnes 8y ago
The downside is that your urls are long, ugly and incomprehensible.
- zxcmx 8y ago
  The upside is that your business is not totally transparent to outsiders who can figure out how many users, carts, products and messages you are adding each month.
  - pletnes 8y ago
    There must be some other way. I can often figure out the direct url to a software project in bitbucket, but office365 urls are pages long. I somehow doubt atlassian is as transparent as you say. Disclaimer: not a web dev
llao 8y ago
If trying more or less random URLs of your service is an issue for you, you have an issue.
- megaman22 8y ago
  True, you absolutely should have security and authorization setup. But if the server replies to the request with a 401 or 403, rather than a 404, you at least know that there is something there.
kuschku 8y ago
This is a massive issue with pastes on GitLab. Unlisted, private, public snippets all get links such as https://gitlab.com/snippets/1712835 https://gitlab.com/snippets/1712835 If you have an instance with few users, you can just create a new snippet and then auto-decrement. e.g. I just found https://gitlab.com/snippets/17128 https://gitlab.com/snippets/17128 this way.

drawkbox 8y ago

UUID are the way, GUID for those in Microsoft's lands. Not only will you never run out but you don't need a round trip to the keymaster, horizontal scaling, clustering and vertical sharding even are all way easier due to that. This removes a single point of failure entirely when the keymaster is no longer needed. Using ints for keys for profiles/users and many other things were needed way back when processing/db/disk/memory and performance from that were a problem, no longer. Do your part, join the UUID revolution. Also, if you were a piece of data, would you not want to be unique across all the databases, storage and services? You've heard of Roko's Basilisk right? Do not disappoint.

kasey_junk 8y ago
I’ve often wondered where the tipping point is where you do start having to worry about collisions. Is frantic “fix all the uuid breaking code” the jobs boost for programmers 20 years from now? 100? It seems unthinkable now but who knows...
- drawkbox 8y ago
  We'll be good until at least sentient AI takes over and they can solve it for us, or them.
sethammons 8y ago
We've had multiple collisions with uuid v4. I'm not overly familiar with the examples, but in one case, the collision was found because the collision happened in the same account! Customer: "Why do these two events have the same id?" Us: "Wow." I think we determined that it was a limitation in the random number generator in the Perl lib we were using. To avoid that, I believe the solution was to go with uuid v1 plus a nonce of some sort.
- cesarb 8y ago
  If you have collisions with UUID v4, something is really broken with your UUID generator. It's not a "limitation", it's a critical bug.

edejong 8y ago

Other advantages of UUIDs: - client can generate the UUID, allowing eventual consistency and retrying using distributed DBs (other DB is on phone for example) - merging of DBs is easy - allows capability based access control (you can’t guess the UUID, you don’t have access) - can use a bit or teo to encode production vs development IDs, so cross contamination of systems is less likely

deleted 8y ago

[deleted]

malingo 8y ago

This post discusses using UUIDs as primary keys (but never exposing them), and an additional integer key on each table as the public facing ID. https://begriffs.com/posts/2018-01-01-sql-keys-in-depth.html https://begriffs.com/posts/2018-01-01-sql-keys-in-depth.html HN discussion: https://news.ycombinator.com/item?id=16050047 https://news.ycombinator.com/item?id=16050047