51–60 of 107 posts
This is missing a checksum which helps secret scanning avoid false positives in other high entropy strings. See for example: https://docs.github.com/en/code-security/secret-scanning/sec...
Crockford has a checksum though
They don't appear to check validity though? I haven't tested it so maybe someone else can double check.
I guess this is an unpopular opinion given the existing comments, but I don't get it. They spent time and energy on this instead of writing features or fixing bugs and I don't think it matters at all. The only interaction I have with my API keys is copying them from one place to another. If I need to manually identify a key then putting the first or last few chars, whatever they are, in my working memory is more than…
Agreed. I cant see why anyone thinks this was worth spending time on rather than just using the standards which everybody else does. Nobody types out api keys so there is no need to make them friendly to say or remember. After you have copied and pasted them once into your db, you are never going to seee or use that string again!
Earlier quoted context omitted.
I totally agree. This looks like a pretty new startup too. I would be livid if my team had spent so much time on this instead of building capabilities to get the startup traction.
Yall are so dramatic. It's a trivial library to write. 99% of it is just deciding what you want the output to look like + writing the blog post.
Earlier quoted context omitted.
Why should anyone vendor a dependency in a critical functionality for three lines of code ( https://codeberg.org/prettyid/js/src/branch/master/lib/index... )?
multiple dependencies, Also requires two other packages to run its 3 lines of code. "dependencies": { "@scure/base": "^1.1.7", "uuidv7": "^1.0.1" }
One of the best things you can do to your API key is to give it a fixed prefix. Makes it very easy to tell that you have the right string, to detect accidental secret leakage, etc... IMHO this makes key much more beautiful than any internal structure.
Dashes in API keys are really annoying. Double-clicking doesn’t select the full key, which just adds extra hassle. It would be much better if they used a continuous string without any separators. Makes copying and pasting way easier, and doesn't affect security at all.
They realized that and were pleased with themselves. > The dashes do remove easy double-click copying, but we think this a fine trade off for readability. We don't want users copying and pasting them everywhere, in fact we want them to be handled with care. Ideally, users copy each key exactly once - when they generate the key from our dashboard - so we added a copy button to our UI to solve that case Don't even thin…
I guess this is an unpopular opinion given the existing comments, but I don't get it. They spent time and energy on this instead of writing features or fixing bugs and I don't think it matters at all. The only interaction I have with my API keys is copying them from one place to another. If I need to manually identify a key then putting the first or last few chars, whatever they are, in my working memory is more than…
Disclaimer: I built it.
Earlier quoted context omitted.
Yall are so dramatic. It's a trivial library to write. 99% of it is just deciding what you want the output to look like + writing the blog post.
Yeah, the code is easy but navel-gazing and agonizing over the prettiest way to replace a long jumble of dash-separated lowercase characters with a slightly shorter jumble of dash-separated uppercase characters is an insane thing to spend any time on at all. Convince me this has any commercial value and isn't just bikeshedding.
The resistance to it is part of why most engineer-types like HNers can't build UX. They think it's all agonizing and navel-gazing, so they don't deliberate over anything. And they don't practice it, so when they see someone making deliberate UX decisions, even trivial ones, they think it must have taken a lot of time.
Good UX comes from a chain of trivial-looking decisions in isolation and a culture of caring about it.