I'm having trouble imagining who would want to use this. What's the environment where you would have curl and a need for generating UUIDs, but wouldn't have access to uuidgen or similar?
Yeah, I'm just really confused. If you're at a CLI, you probably have uuidgen. And I'd assume there's something similar on Windows.
If you're writing some kind of application, pretty much every language/framework can generate UUIDs, and even if yours doesn't, just generate a 128-bit number, stamp the v4 UUID bits into it, reformat it, and you're done. Calling out to a 3rd-party service is insane for that use case anyway.
Understandable! I made it for the few times I'm manually testing an API using Swagger or something similar and need a valid(ish) GUID to stand in for some field being sent to the api.
There's no shortage of ways to generate GUIDs, that's for sure!
Maybe a JS App which is made completely out of third party APIs, without anything self-hosted? Not discussing wether this is a good idea or not, though...
I was surprised to see that there is no "built-in" mechanism in JS to generate a GUID. As a C# dev, I'm used to Guid.NewGuid()
Why would you make an http request if you can just google a 3-line JS solution? You're just generating a large random number and formatting it as a UUID.
If you google "generate uuid javascript" you can find approaches from Math.random to node/browser `crypto` module to shelling out OS random.
One of the main benefits of guid generation is that you don't need to synchronize with anything to generate a unique ID, so it's weird to incur an http request, especially to someone else's service. At that point you might as well just phone home to your own service.
JavaScript Math.random() should never be used for UUID generation. You will get collisions even at small scale.
window.crypto.getRandomValues() should be used instead.
The quality and seeding of Math.random() is implementation-dependent and not generally good enough everywhere to prevent collisions. Many seed with the just the system time.
Source: I have personally seen such collisions in a production web app with 700k users. A Web search for “Javacsript GUID collision” shows that many others have as well. We switched to the cryptographic generator and the collisions disappeared.
Only uuid v3/v5. Anything is possible if that's what you want. But 128 (or 122) bits of random are usually what you want when you think of guid.
Most people format 128-bit random numbers into a UUID just so it's obvious at a glance what it is: a guid. Even if it's not technically a UUIDv4 because it doesn't have the magic bits.
In what world is it safe to rely on an external service to provide GUIDs for you? Where's the guarantee that the service won't one day start manipulating GUIDs? Now you have a major attack vector.
That seems hyperbolic to me. If you rely on UUID for security, it seems, to me, something is wrong in your architecture and the security flaw lies there.
When would you, legitimate, rely on GUID/UUID for security?
You can totally use uuid4 as password reset tokens, and they could be slightly nicer than random urlsafe strings for your database, provided they’re generated securely, not from givemeguid.com.
Depends on the GUID. Some of them include version numbers, timestamps etc... I would need to code the http request too. The problem with web services is that they might disappear again, so I would maybe use it on a website, but not for production software.
If you're writing some kind of application, pretty much every language/framework can generate UUIDs, and even if yours doesn't, just generate a 128-bit number, stamp the v4 UUID bits into it, reformat it, and you're done. Calling out to a 3rd-party service is insane for that use case anyway.