Hacker News Reader

Comment by billyhoffman | Hacker News Reader

So let's just deliver all our business logic as JavaScript to an entirely untrustworthy client! Whats the worst that could happen?

View on HN

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.

[1] https://www.owasp.org/index.php/Main_Page

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?

An e-commerce platform on Hoodie would also do final validations 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).

Hoodie works no different than Gmail. What’s the worst that can happen there?

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 :)

Well you sure as shit aren't going to see "hoodie.account.signUp(username, password);" in Gmail's client-side code.

Gmail's code base is not a "offline first, mobile first" platform. The API that is exposed to the client-side is fairly light (watch the traffic).

I highly suggest use research "business logic flaws" in web apps. Anything Jeremiah Grossman has said on this topic is good stuff.

They have frontend code that will talk to /singup or whatever the route for creating an account is. Hoodie does nothing different.

Thanks for the pointer to Jeremiah, though :)

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.

the signup seems to be handled by couchdb.

On a related note, how does MailChimp have "confirm subscription" link IN MY GMAIL LIST?

http://cl.ly/image/1o1K2f202T3c

Gmail's "Actions" API.

https://developers.google.com/gmail/actions/reference/one-cl...

It's a Gmail feature called "Actions" and was launched back in 2013:

https://developers.google.com/gmail/actions/actions/actions-...

I'm actually surprised so few companies have implemented it thus far.

The difference is server-side validation of untrusted client requests.

Hoodie does server-side validation of untrusted data.

Not yet. https://github.com/espy/hoodie-plugin-tutorial

"This document describes functionality and features that don't exist yet."

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 :)

There, I fixed it :)

https://github.com/espy/hoodie-plugin-tutorial/pull/13

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.

Hoodie has plugins, so you're not limited to client-side only logic.

http://hood.ie/#plugins

Sharing the business logic is less of an issue than the business metrics that get leaked when you include user ID's in your source code.

Reply on news.ycombinator.com