I find this "backendless billing" approach fascinating because it highlights the tension between DX and security. As someone who's built payment systems, I understand the appeal of reducing backend boilerplate, but there's always a security tax to pay.<p>The real issue seems to be that they're trying to make billing "feel frontendish" when it's inherently a backend concern. The encryption approach in Part 3 is essentially recreating auth tokens but with extra steps, as others have noted - they're basically reinventing JWTs.<p>What struck me most was the security vulnerability they discovered with server actions. If you can make calls with any customer_id without verification, that's a textbook IDOR vulnerability. A simple curl request with a different customer_id would let you upgrade/downgrade other accounts! No amount of client-side magic can fix fundamentally flawed authorization.<p>Their conclusion is telling, sometimes the "boring" approach (proper backend routes with auth) exists for good reasons. I appreciate their transparency about the journey though, we learn more from these explorations than from pretending everything works perfectly from day one.
Like others, quite confused here. If it requires server actions, then it's not backendless? Just say you are simplifying the backend and how you interact with it, if that's what you are doing.
I'm rather confused by this article - I've made products and pricing services, and just on the first line its said that billing requires webhooks and state syncing.. but why? Is it a way to utilize payments in an otherwise static site? Whats the benefit? You can absolutely accept payments without webhooks. Please help, I really don't understand the niche!<p>I'm left with the sense that this is a sort of solution that's trying to do auth permissions via the billing process, without calling it auth. Any access token you'd set up for auth with roles or permissions can give you access to both a customerId and whatever access grants you'd want to give.
Reading the blog it seems the engineers there lack basic knowledge about safety (see their multiple different approaches where they learned "after the fact" that their approach wasn't secure)... this doesn't inspire a lot of safety
I don't get it. If someone gets a hold of the encrypted customer ID, can't they impersonate the customer? Is it just that the customer ID is guessable?
I find everything about web technology nowadays to be extremely obtuse.<p>I am mostly an embedded/Linux driver engineer, but I think I know the basics of HTTP, REST APIs, Docker containers, how the web works overall etc.<p>But, like. What are we doing?<p>What do you mean make the billing backendless? Obviously there has to be a backend to process the payment. What are you even saying? You are presumably not building a distributed blockchain - and even that requires permanent nodes.<p>Same with serverless (which are just Edge Functions and could just be called that, or serviceless, if you really wanted to define it negatively).<p>If these people named NoSQL, it would be called databaseless.
> Server actions are public, unauthenticated routes<p>Why can't they be authenticated? That seems like the obvious fix. Otherwise how you are handing out the correct customer_id unless you authenticate somehow?<p>This scheme also complicates API key rotation, although you can work around it by trying to decrypt with both the old and new key if you use e.g. authenticated encryption.<p>This also has no mechanism for expiration (besides API key rotation). If you add an expiration time and sign it, then you essentially created an authentication token that you use as the customer_id.
Why not just authenticate the user against that customer_id, and then you can pass the customer_id around as much as you like (or have a surrogate key to it for a little more security)?<p>A JWT with the customer_id (or surrogate) in would let you do that in serverless function.
If you don't have a backend, how do you make sure I'm billed?<p>What's stopping me from opening the console and calling the "addMoreCredits" function? Why can't I just edit the code to remove any mention of consuming credits?<p>I think you're about to discover why most multiplayer games have moved authoritative simulation to the server.