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.
Is this just a "random" UUID or does it meet specs of RFC 4122? I have seen countless times when it was just generated as {8}-{4}-{4}-{4}-{12} with complete random numbers. Well, works for most applications...
This is what I use to generate guids with autohotkey:
::;guid::
guid := GUID()
StringLower, guid, guid
Clipboard := guid
SendInput,^v
return
GUID()
{
format = %A_FormatInteger% ; save original integer format
SetFormat Integer, Hex ; for converting bytes to hex
VarSetCapacity(A,16)
DllCall("rpcrt4\UuidCreate","Str",A)
Address := &A
Loop 16
{
x := 256 + *Address ; get byte in hex, set 17th bit
StringTrimLeft x, x, 3 ; remove 0x1
h = %x%%h% ; in memory: LS byte first
Address++
}
SetFormat Integer, %format% ; restore original format
h := SubStr(h,1,8) . "-" . SubStr(h,9,4) . "-" . SubStr(h,13,4) . "-" . SubStr(h,17,4) . "-" . SubStr(h,21,12)
return h
}
I remember several years ago using https://newguid.com which was pretty much the same thing - no page furniture, just the new guid. Sadly the domain seems to be on sale now!
Why would you want to hash random bytes? The only thing you could theoretically achieve by that would be decreasing entropy. Just do openssl rand -hex 20 (or any other number of bytes as needed, or -base64 for another encoding).