This account is a replica from Hacker News. Its author can't see your replies. If you find this service useful, please consider supporting us via our Patreon.
| Official | https:// |
| Support this service | https://www.patreon.com/birddotmakeup |
parliament32
- 0 Followers
- 0 Following
- 4 Posts
This account is a replica from Hacker News. Its author can't see your replies. If you find this service useful, please consider supporting us via our Patreon.
> can anyone on the product side actually predict traffic
Hypothetically, could you not? If you engineer a bridge you have no idea what kind of traffic it'll see. But you know the maximum allowable weight for a truck of X length is Y tons and factoring in your span you have a good idea of what the max load will be. And if the numbers don't line up, you add in load limits or whatever else to make them match. Your bridge might end up processing 1 truck per hour but that's ultimately irrelevant compared to max throughput/load.
Likewise, systems in regulated industries have strict controls for how many concurrent connections they're allowed to handle[1], enforced with edge network systems, and are expected to do load testing up to these numbers to ensure the service can handle the traffic. There are entire products built around this concept[2]. You could absolutely do this, you just choose not to.
[1] See NIST 800-53 control SC-7 (3)
[2] https://learn.microsoft.com/en-us/azure/app-testing/load-tes...
> For mail, couldn't we come up with a mail-DNS, that authenticates senders?
So RFC 7672? https://datatracker.ietf.org/doc/html/rfc7672
RFC 7672: SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS).
I certainly see you whining a lot about SAML in your history. This lines up with my "SAML is hard" comment above -- SAML is filled with footguns and various perils, but that doesn't necessarily make it bad. OIDC is certainly better in a few aspects (note trading XML parsing for JSON parsing is not one of them), but the killer SAML feature that you (and by you, I mean fly.io, to be clear) is missing is being IdP-agnostic. You cannot reasonably expect that those two vendors will cover even half of your potential enterprise user base; and yes, for anyone working in an even remotely regulated industry, not being compatible with our SSO ensures you get dropped even before the evaluation phase.
My favourite slop-generator summarizes this as "While SAML is significantly more complex to implement than OIDC, its design for robust enterprise federation and its maturity have resulted in vendors converging on a more uniform interpretation of its detailed specification, reducing the relative frequency of non-standard implementation quirks when dealing with core B2B SSO scenarios." That being said, if your org is more B2C, maybe it makes sense you haven't prioritized this yet. You'll get there one day :)
That would be great, but
> Fly.io supports Google and GitHub as Identity Providers[1]
How about you just support SAML like a real enterprise vendor, so IdP-specific support isn't your problem anymore? I get it, SAML is hard, but it's really the One True Path when it comes to this stuff.
