Does anyone have experiences with ZeroSSL? Caddy has been building in support so I think it could be a drop-in replacement for Caddy/CertMagic/ACMEx users.
998 karma · joined August 19, 2019
Email: colin@clerk.dev
I'm interested to know - what's the sales pitch for DO over Render? I'm noticing some pricing differences but at first glance it seems they tip Render's direction. I'm also noticing Render is a bit further along (persistent storage, cron jobs, custom domains).
https://www.youtube.com/watch?v=60qhpmQHlCU
We're hiring a frontend engineer to lead the development of our dashboard, the modules deployed on our customers' websites, and our NPM packages. We develop with Typescript and React, but our modules can be deployed in any stack.
Clerk is still a small company. You'll be joining a team of 5 and working most closely with our lead backend engineer (who is responsible for the apis you'll interface with) and our product designer (who is responsible for the user experience and design).
We are well-funded by founders and early engineers of Stripe, Segment, PagerDuty, and Facebook, and plan to launch before the end of the year.
Please reach out to colin@clerk.dev
Clerk is hiring engineers and designers. We're building developer tools for user management. We offer APIs, as well as a "Stripe Checkout" for Sign up, Sign in, and Profile management.
Out of the box, we provide the authentication features that all software should have:
- Two factor authentication
- Single sign on
- Passwordless
- New device notifications
- Password breach notifications
- Multiple signed in users at once
Our stack is in Go and React. The team is currently 3 and we expect to grow to 6 in the next few months.
Please reach out to colin@clerk.dev if you're interested.
Nice to see more and more pushed to the edge, and good that it's only the beginning of the week.
I'm a little surprised they stuck with the isolates model when moving to include generalized compute. We found isolates to be ideal for a cache layer, but it doesn't have first class support for many languages: https://community.cloudflare.com/t/native-golang-support-for....
Very interested to see if they expand on their storage options throughout the week. Additional consistency guarantees in their KV offering would make it more competitive with Dynamo. I'd love to see a managed relational offering like Cockroach, or perhaps the addition of CockroachCloud to their bandwidth alliance.
One point I'm disappointed about is that they list API Gateway and DNS Queries (per MM requests) at $0.
This may be true if you're deploying on a single domain with Cloudflare, but if you're a SaaS and need SSL for custom domains, Cloudflare bumps you into their enterprise offering that costs a minimum of thousands per month, and (we found) netted out to about $5-10 per month per hostname: https://www.cloudflare.com/ssl-for-saas-providers/
(I recognize this is a different way of metering, but listing both at $0 feels like they're arguing DNS & TLS termination cost nothing at Cloudflare, and that was far from our experience)
I'm a little surprised they stuck with the isolates model when moving to include generalized compute. We found isolates to be ideal for a cache layer, but it doesn't have first class support for many languages: https://community.cloudflare.com/t/native-golang-support-for...
Very interested to see if they expand on their storage options throughout the week. Additional consistency guarantees in their KV offering would make it more competitive with Dynamo. I'd love to see a managed relational offering like Cockroach, or perhaps the addition of CockroachCloud to their bandwidth alliance.
One point I'm disappointed about is that they list API Gateway and DNS Queries (per MM requests) at $0.
This may be true if you're deploying on a single domain with Cloudflare, but if you're a SaaS and need SSL for custom domains, Cloudflare bumps you into their enterprise offering that costs a minimum of thousands per month, and (we found) netted out to about $5-10 per month per hostname: https://www.cloudflare.com/ssl-for-saas-providers/
(I recognize this is a different way of metering, but listing both at $0 feels like they're arguing DNS & TLS termination cost nothing at Cloudflare, and that was far from our experience)
You will be responsible for building a front end architecture that is easily extensible and customizable by our customers. You will help us define everything from the methods in our client-side SDK, to the API endpoints our SDK calls, to whether we embed or redirect, to the strategy developers will use to add custom CSS.
We're looking for an engineer who will approach our challenge from first principles to find the best possible solution. The questions you will encounter range from the more typical: will Rollup or Webpack result in meaningfully smaller downloads? To the more esoteric: can we shave off 50ms to first paint by leveraging JSONP?
If this sounds exciting we'd love to talk! We're venture funded and looking to launch our beta product soon. Email colin@clerk.dev for more information.
There's Spreedly, which at first glance might be more of a marketplace.
But then there's also an argument that Stripe itself is an API-as-a-marketplace, where they support different card providers/types, ACH, and a host of global methods.
Is one interpretation more correct than the other? (at least as it relates to an investment thesis)
---
Another example is the Priceline API (and the GDS's before them), which I believe solidly qualify as an API-as-a-Marketplace under this definition.
Clerk is building an API for user and team management. We give developers drop-in UIs for sign up, sign in, profile management, team onboarding & management.
You will be joining two technical founders as the first employee, helping us launch in the next few months.
Ideally, you're comfortable developing anywhere in the stack, and have a strong eye for speed and reliability. Knowledge of our stack isn't strictly required, but we use:
- Typescript and React for our UIs
- Golang for our APIs
I believe I can split out the cost and salt. That would let me:
1. SELECT the user's salt and cost from a table that is accessible with my web app credentials.
2. Run bcrypt on the user-provided password with the selected salt and cost within my webapp.
3. Ask my stored procedure if my resulting hash matches the hash in the database, even though I cannot SELECT the hash directly with my web app credentials.
Am I understanding this correctly? I imagine it would have been easier pre-bcrypt, when generating salts was less abstracted away from the developer.
I can't think of a reason this wouldn't work, and it adds a layer of security if implemented properly. But I say that hesitantly, as I would all things crypto, particularly since I wouldn't consider it common practice and I'm not sure if I'm overlooking something. I'm pretty sure I'd need to hack on bcrypt-ruby more than comfortable to actually implement.
* I say normally because that's what the wiki says and how bcrypt-ruby behaves, but I haven't done wider research.
I've never seen it done this way, but I think postgres pgcrypto could support this.
If I had to guess, I haven't seen it done this way because authentication frameworks are not normally in a position to lock down access to the database in this way (e.g. it couldn't create a password table that the web app credentials can't see, because it's integrated into the web app and uses the web app credentials to create the password table). The way they typically behave is: - When updating password, run bcrypt in the web server and INSERT - When testing password, SELECT the bcrypt hash down to the web server, and test on the web server.
Have you used this stored procedure strategy in production? I'm particularly interested if it's caused any challenges with resource usage in the database server?
The top answer in this stack overflow question makes the argument that you should bcrypt in the web server to lessen the time it's unhashed: > Use php bcrypt if you can, it'll lessen the time that the password remains unhashed. https://stackoverflow.com/questions/2647158/how-can-i-hash-p...
I'm not sure I agree with this argument, unless perhaps the database is hosted by a separate vendor (which would mean another party is receiving the unhashed password). Also note: the strategy proposed in that answer doesn't have the benefit of a stored procedure preventing a SELECT all, so maybe the less time argument makes sense in that case.
Perhaps there's a valid discussion around - is this going overboard? Is preparing for a leak of web app database credentials an attack vector we really need to prepare for? If we do, are password hashes the critical data we need to be securing in this manner? When hashes leak I've been asked to change my password as precautionary measure, but hashing algos are such that this event shouldn't be catastrophic. Unlike a credit card number leak, for example, which would cause a bigger headache.
I do still wish the ML stuff weren't there, though. As a developer for a small company that's trying to become a big company (and develops on these boundaries), I fear we'll build something that works one day, but the next will be classified and the rules will change.
I'd rather have a policy that forces big and small sites to follow the same rules. Between storage access and link decoration detection, WebKit seems quite close to being able to detect cross-site tracking as it happens rather than via classifier, and I'd hope that could one day replace the ML component.
The identity "Me while I'm visiting nytimes.com" is distinct from the identity "Me while visiting cnn.com".
To me, this means all client-triggered requests while my address bar ends in "nytimes.com" will have a distinct set of cookies that is only drawn from while I'm on nytimes.com.
I prefer a rules-based solution to an ML-based solution. ML is more opaque and it's harder for developers to know when their solution will run afoul of the classifier.
Are there significant compatibility problems this would cause?
Issue is Google's third suggestion, "A per-first-party identity can only be associated with small amounts of cross-site information", is clearly advertiser-focused, not privacy-focused.
I hope all can rally around the partitioning concepts and leave the others behind.
[1]https://github.com/michaelkleber/privacy-model [2]https://webkit.org/blog/8828/intelligent-tracking-prevention...