5 ms·
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 buil
by ZenJosh 13y ago
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 13y agoNothing, all they can do is fuck up their own data.
- alexaasp 13y agoWhich 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 13y ago1. 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 13y agoThe 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 13y agoHoodie 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.