Desktop clients have been delivering business logic to clients for a very long time with few problems. Web powered apps are similar. The issues involve protecting data stored in the cloud, communicating over secure channels and client security. JavaScript powered applications running in a browser have many security considerations, but they're manageable if you have security aware engineers building your application. Knowing about OWASP[1] helps.
Are there any e-commerce platforms that trust the client to do all the business logic for an order/checkout? If so how do they prevent client side tampering with the business logic without redoing it on the server side?
It seems a naive proposal at best to suggest the client would get business logic in lieu of the server. Typically clients need to assist users and they do that by use of business logic based validations and constraints.
Oh I agree but the GP seemed to indicate that trusting client side logic is a solved problem for web apps. I was curious if he had any sort of examples since it doesn't seem to be something related to the issues he listed.
we don't deliver all our business logic as JavaScript to the client, we just provide a nicer API. All security / scaling / business logic still lives server side.
Take hoodie.email.send(properties) as an example. It just the same as `POST /email` with email properties JSON, with the only difference that it's simpler to understand and to handle for frontend people, and it works offline (syncs when connection is back).
Can you give an example for why that signup code is bad? In the case that I'm using Hoodie with CouchDB, wouldn't Hoodie just AJAX post a user document to the CouchDB _users database (which is a good implementation)? All of the access control would be in the hands of the server with minimal (if any at all) security logic in the front end.
Yeah, but you're going to see a <form> that POSTs to some target URL, with username and password as fields. The only thing protecting the plaintext password from leaking is SSL. POSTing a XmlHttpRequest is equivalent.
I’m a Hoodie developer, I know what Hoodie does and doesn’t. That disclaimer is just there because some of the things don’t yet work as documented. The particular feature is definitely in existence :)
How is one of the first apps to popularize AJAX, developed on top of a proprietary cross-compiling framework by a top-3 web giant "no different" from Hoodie? Obviously you're getting at some specific point that is completely obscured by the ridiculousness of the comparison. Hopefully it's more than "client-side logic can be useful" because that much is obvious on its face. It's also obvious that the idealized promise of no-backend falls apart pretty quickly for a majority of real world apps. So what is your point exactly?
Sorry, from “delivering business logic to the client” perspective, Hoodie is no different in concept on that angle. Lots of things are very different, of course :)
I've been delivering apps just like that for 15 years without problems. As far I can remember there hasn't been an single case where this would have been a real problem.
I'm well aware that it isn't a perfect solution but it just works.
