[ZenJosh]

This looks pretty optimal for a little app I'm building. I've been bolting bits to Sinatra and using it as a half-API-half-template engine for a frontend I built, this looks far cleaner. I'm curious about security though, what's stopping a user from plugging in random data via the console?

[janl]

Nothing, all they can do is fuck up their own data.

[alexaasp]

Which sounds kind of bad, if that is the case.

1. Even if the users are idiots you shouldn't let them ruin their own application experience. 2. I would never put anything remotely connected to security and user privileges in the same storage accessible by users, so I would have to set up a separate service.

[janl]

1. what if that idiot messes with gmail’s web console?

2. Security handling is purely server-side. You can’t fake your way without using a proper auth-channel.

[alexaasp]

The distinction here is that Hoodie is supposed to free you from dealing with servers, but that is currently limited to scenarios where you have users with uniform access privileges and no concerns about users messing around with their database information. So until they add modules most projects will have to get down and dirty in the end if they want to attach any kind of privileges to users. In both points 1 and 2 you need to have some server side logic beyond Hoodie.

[janl]

Hoodie can only promise to free you from worrying about the backend by providing one that you can just use.

The sharing module e.g. makes heavy use of server side logic and database security and access control features. The Hoodie frontend just makes it accessible to frontend devs.