Presigned post lets you set content-length-range: https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-authen... You can specify content length on presigned PUTs, but it needs to be set as a header and added to the signed headers for SIGv4. It can't be set as a query param.
We have a Storybook set up that displays components rendered with PHP and Twig using a REST API endpoint on our WP install. Pretty crazy setup but it works. We use play functions in Storybook to fire the request and just render the returned HTML from the server.
SSO is not a requirement for secure software. It’s a requirement for enterprises because otherwise they have to manually keep track of everyone’s accounts everywhere, but that’s a management issue not a security issue (unless managed poorly).
Admittedly for many SaaS and OSS offerings SSO is an enterprise-only feature while it doesn’t have to be, but it’s the best discriminator they have to separate cheaper plans from enterprise plans. The alternative is to charge more for all plans, but then you lose out to the competition that does play this enterprise tax game.
For software to have secure authZ/authN, it should have robust 2FA mechanisms including WebAuthn, properly integrate with access tokens, and support scoped third party access.
Most software only offers simple username/password auth, or a paid SSO option as the only way to get 2FA working. And SSO makes it much easier to revoke access or change passwords if necessary.
I'm running hundreds of services self-hosted just for myself and less than a handful of close friends. I'm using SSO for all of them.
I had to patch SSO into countless services and I actively maintain forks with self-reimplemented enterprise features for almost half of them.
I had to do similar changes to get S3 support, as I use the AGPL version of Minio as storage backend for everything so I only have to setup backups in a single place.
The only reason one could try to argue that these are enterprise only features is if you assume personal users have no need for 2FA or backups.
I was hoping for some interesting insight to be shared, but no it’s just a shallow opinion piece on why E2E is better than unit tests for web interfaces, without really explaining why.
The author misses that component tests don’t have to be like unit tests at all, they are more like integration tests if you test entire pages (which are components too), use actual user interactions and mock only the I/O (mostly network) layer. It’s like E2E without spinning up a backend.
As someone advocates for and runs E2E tests, you're going to be hard pressed to find any one writing about it.
The main objection heard will be: "It takes x hours and n servers to set up an E2E environment."
Infrastructure is hard, and with cloud functionally unlimited, so people write a mock and move on with their life.
To do E2E well your culture needs to support it. You need to be able to spin up, run and summarize an E2E test in less than 20 minutes. Set your test up to END on the hour (not start, end) SO that if there is an outage no one can make the excuse that the "meeting already started". If the test fails every one who has changes in that build drops what they are doing and treats it like a production outage. The technological magpies, collecting shiny things and adding them to the stack has to stop, because you dont want to add "new tech" to build time. You may need to run some of your own infra to get this done. Some servers in a closet some where will do wonders for your bills.
Because you're always building your environment from scratch, in the event of a real disaster you know what it takes to put a large chunk of your environment back together. Your like going to have a pretty lean stack, one that scales diagonally (at this point go look at AWS spot pricing and how much you can save if you can scale that way).
That isn't to say you should not unit test. Things that are clearly stand alone, like well defined validation, things that are ugly (that 20 condition switch statement that powers some esoteric edge case of business "logic") should get unit tests. Places where you can leverage fuzzing easily should have unit tests! Anything that has a dependency tree or needs a mock, should be skipped and addressed with an end to end test.
What will you get in the end? A production environment with every bit of unneeded complexity stripped from it (and probably a lower cloud bill). An aversion to adding anything that doesn't have VALUE to your stack. A ruthless eye for what qualifies as "bloat" (hint, a LOT of it is bloat). The removal of code for codes sake (mocks) and layers of duplication (an E2E create user test can exercise a lot of code, and replace a lot of unit tests at various levels). The whole team having a much better understanding of how your infrastructure is built and deployed.
I still don't see it anywhere other than the small caption mentioning ElixirConf (still not obvious that it's meant for Elixir) and the mention of Phoenix + Elixir ecosystem under the "Compatibility" section (way too far down the page).
Yep, because I pushed a different change and accidentally removed the word Elixir again. Pretty stupid of me, it’s been a hectic day. We’re putting it back as we speak.
Why this is getting blamed on JavaScript / Node.js is beyond me. Microservices were/are all the rage in Java/Scala land, and seemed to initially be pushed by (Dev)Ops engineers' desire to roll their own Kubernetes cluster (or whatever came before). I've been on multiple such project and I always loathed the additional complexity (especially combined with actors/event sourcing and Cassandra). Node.js was limited to some frontend tooling that only ran locally or in CI.
I think the author meant "Web developers", not specifically "JavaScript developers". There's just a very big overlap between the two.
So, Java and friends fits perfectly into this pattern. DevOps (saying as someone who used to be "Ops" w/o the "Dev") is also largely a Web phenomena. If you were exposed to Web development some time in your career, but then moved away from that, Kubernetes will definitely trigger PTSD in you. It's Web developers writing system software, and they don't really know how to do that.
LAN parties got me into casemodding. I was always more interested in looking cool (to this particular crowd) than actually playing games [1]. I always picked a seat at the end of a row, close to the catering so people would come over to take a look.
This quickly got out of hand with sponsors (Cooler Master, Silverstone, among others) and dragging my builds to casemodding contests and trade shows (CEBIT Hannover). I was still in high school. Good times.
Is nobody concerned with the fact this tool scans your repository contents? This tool is mostly intended for use with private projects, not open source, so I would expect a LOT more scrutiny (and options) around security.
