thank you!
@seveibar
From 1/16/2015, 3:19:54 PM till now, @seveibar has achieved 417 Karma Points with the contribution count of 70.
Recent @seveibar Activity
Base62 is a great alternative! The libraries/alphabet around base58 are fairly common thanks to cryptocurrencies, but base62 libraries are generally available and easy to produce if needed.
The signature approach is interesting because it couples the short token the api key, so they're a pair rather than totally independent. Introducing a signature changes the math to create the shortest possible API key with at least 128 bits of entropy (that are not stored server-side). But it's worth looking into!
Yep you've got it! The consumer gets the full api key containing the prefix, short token and long token, e.g. "mycompany_BRTRKFsL_51FwqftsmMDHHbJAMEXXHCgG". The database stores the short token, and a hash of the long token.
Thanks, yes I agree the ".split(_)[-1]" is ugly and there should be validation on the key prior to operations on it!
Making an issue :)
I think this is an excellent idea! However, we didn't like the aesthetic of the version that included the domain- I'll admit it's not great reasoning.
my mistake! fixed :)
Appreciate the thoughts on the naming/exceptions and thanks for taking a look at the implementation! Definitely making some adjustments tonight.
I think your thought on bcrypt/scrypt vs SHA256 is super interesting here. The long token is treated a lot like a password, so we should treat it similarly and use slow hashing. However, unlike a password an API key is repeatedly used for authentication instead of being exchanged for a session token. I don't think this meaningfully changes anything- so I think you're right that bcrypt/scrypt would be a better choice!
Edit: Also see koomla's answer!
thanks for taking a look! I've created an issue on the repo and should be able to address these tonight :)
fixed thank you :) - and great suggestion!
edit based on your edit: Added your recommendation to the README, thank you!
Author here: I was curious what HN would think of this token style, we're currently using it for getseam.com . I think it has a lot of advantages over other token styles (e.g. double-click to select, standard alphabet, compatible with secret scanning). Although this is a typescript library, we originally designed this API key for use in Ruby on Rails and the pattern should be fairly portable.
Show HN: Prefixed, dual-token, base58 encoded API Keys
100 points • 54 comments
Surprised nobody has mentioned Row Level Security or RLS for postgres. It allows tight and domain-specific access control to each table through security policies you design. It's so effective at controlling access that Postgrest (postgrest.org) uses it to completely manage the access control for the HTTP API that's used to access the underlying postgres instance.
What I personally like about RLS is that I can test every access scenario for a user's session in unit tests, and I don't have to worry about application bugs allowing one user to access another user's data or accessing tables that their session token/api key doesn't allow them access to.
I would build out more of it and list it for free (I've dropped in a lot of TODO sections), I'm not sure if "progressive release" is possible, if it's not, we wouldn't want to release it as is. I have a lot of team members who I have to teach this type of build system, and the material online isn't very opinionated so I end up seeing a lot of incompatible configurations.
I submitted a quick course for review. I love the concept and the execution is snappy. Like some others, I'm concerned about the pricing model because I have no way of exporting the content I create on the platform outside of it- so unless I want to lose my course it seems like I'll need to pay forever.
I couldn't find a way to reorganize blocks or lessons, or even insert a block in-between two other blocks. I was surprised to be confused here because the rest of the platform is really seamless.
Sent this along to some coworkers, thanks for the detailed answer!
FWIW I also posted to StackOverflow and your answer might reach some others there! https://stackoverflow.com/questions/68354366/why-shouldnt-yo...
Thanks again :)
Ask HN: Why shouldn't you have redundant states represented in a SQL schema?
2 points • 3 comments
Yep, like i said the cloud provider will lie about best practice to have you bake them in. Vercel is the best of the bunch IMO because their infrastructure components (e.g. micro) are open-source. But they have great workflows for monoliths tucked away.
Render looks very cool, thanks for sharing :)
Monoliths and serverless are not exclusive. Serverless applications can and should be built as monoliths and should be able to run as a monolith e.g. via a container. Any platform that prevents you from doing this is part of the 90% bad group.
Your knowledge probably mostly carries over. Stateless application architectures were around before serverless, Serverless just enforces most of the patterns. For example, Rails promotes a monolithic pattern that scales horizontally thanks to the stateless application principle of maintaining state inside the database (or separated data store) and only having ephemeral state on the server. This wasn't always obvious. But nowadays we know not to store images directly on the server's hard drive.
Rails couldn't have anticipated the computation or memory constraints of serverless, which is why it's incompatible. Serverless is basically just stateless application design within a cpu and memory constrained system.
Serverless Providers and Effective Architectures
6 points • 4 comments
site design / logo © 2022 Box Piper