7 ms·

It all amounts to the same thing: no server means putting your trust in the client. Which you should never do. You don't trust who the client says they are (aut

by bonaldi 15y ago

It all amounts to the same thing: no server means putting your trust in the client. Which you should never do. You don't trust who the client says they are (authentication), you don't trust what the client says they can do (authorisation), you don't trust what they're giving you (validation), It's not something you bolt on later. You have to bake this in from the start, because even the simplest operations depend on it. Posting a comment? Great: are you allowed to post? Who are you posting as? Is there HTML in your post?

buu700 15y ago
You don't trust who the client says they are I shouldn't trust a hashed username and password? How are server-based systems more secure? you don't trust what the client says they can do That's a non-issue if it's handled by ACLs on the server. you don't trust what they're giving you Like I mentioned before, though, for most applications you can trust what they're giving you. Sure, Amazon isn't going to ask the client how much an iPad costs and WoW isn't going to ask the client for the player's stats, but why should an application like Facebook care to verify whether you want to modify your own settings or send a friend request / wall post / whatever? If you attempt to perform an unexpected action (say, post to the wall of someone who's blocked you), the other user's client application logic (which is beyond your control) can still handle the junk data gracefully and simply. Also, later on (when you have more developer time to spare), if you want to for whatever reason, you can easily just deploy a server-side "garbage collector" of sorts to regularly clean up the database without disrupting client-side flow. It's not something you bolt on later. It can be, provided that it's only in the form of new features rather than fixing something which was insecurely implemented to start with. (For example, maybe the MVP is free but the next iteration is freemium and requires server-side price validation.)
- bonaldi 15y ago
  I shouldn't trust a hashed username and password? How are server-based systems more secure? How are you going to verify the password without a server? Passwords are a server-based system. That's a non-issue if it's handled by ACLs on the server. ACLs fine-grained enough to handle modern security scenarios are going to be just as complex as doing traditional validation. Any non-trivial sites are quickly going to get way more complex than just doing it the old-fashioned way. So why bother? why should an application like Facebook care to verify whether you want to modify your own settings or send a friend request? Because privacy is mission-critical for Facebook, and an exploit that allows me to send a friend request to myself as you is an unmitigated disaster for them. And trivial to do in a mostly-client world. Beyond trivial if I have access to the other client, which I am one browser bug or open wifi access point away from having. It can be, provided that it's only in the form of new features And those new features are going to be written in what? Since your MVP's framework doesn't support server-side logic, you're now splitting your code in three. Now you're either in maintenance or rewrite hell, just as you're taking off. That's not one of the good problems to have, it's one of the stupid problems you should have avoided by laying the right foundations at the start.
  - buu700 15y ago
    How are you going to verify the password without a server? Only a dreadfully insecure system would choose to compare plain text passwords over the standard practice of hashing. It makes no difference if the hash is done client-side or server-side; if anything, even with SSL it's more secure to keep the plain text password removed from the network. ACLs fine-grained enough to handle modern security scenarios are going to be just as complex as doing traditional validation. How so? If I can manage my Facebook privacy settings graphically, any developer can manage ACLs in a DB schema graphically. No reason to unnecessarily clutter up code and deal with pointless architectural issues. Because privacy is mission-critical for Facebook, and an exploit that allows me to send a friend request to myself as you is an unmitigated disaster for them. And trivial to do in a mostly-client world. Beyond trivial if I have access to the other client, which I am one browser bug or open wifi access point away from having. Uh, what? If you have access to someone else's account then the game is already lost; no backend can solve that. Since your MVP's framework doesn't support server-side logic, you're now splitting your code in three. Now you're either in maintenance or rewrite hell, just as you're taking off. ...What? Who says whatever framework I use won't support server-side logic? Even vanilla JavaScript or jQuery is fine for AJAX calls. Not sure where you're getting "rewrite hell" from, but you must really hate the client APIs provided by Google, Yahoo, Facebook, and Microsoft.
    - bonaldi 15y ago
      over the standard practice of hashing A hash (like a plain password) is just a meaningless string unless you have something to compare it to. That means you have to store a trusted version elsewhere. Eg: a server. any developer can manage ACLs in a DB schema graphically And the client?. When I as user make you admin of my facebook event, how do I do it? Can my client side code change the access for other users? That might be, y'know, bad. Exploitable. Uh, what? If you have access to someone else's account then the game is already lost; no backend can solve that. Not access to someone else's account, just access to the other client via the network, browser bugs, bad proxies etc. It's a whole flock of blacksheep. There is a world of XSS that is only stopped by having wary, untrusting servers. Who says whatever framework I use won't support server-side logic Hi. This is a thread about Fireball, which is a new BaaS, one that promises no server-side logic. You appear to be defending this idea. Now I wonder if you understand it. We are not just talking about "some code running in the client". If you want to say client side code is fine so long as you have server-side logic for sanity checking, well, yes. Yes, it is. That's my point.

by bonaldi 15y ago

buu700 15y ago

You don't trust who the client says they are I shouldn't trust a hashed username and password? How are server-based systems more secure? you don't trust what the client says they can do That's a non-issue if it's handled by ACLs on the server. you don't trust what they're giving you Like I mentioned before, though, for most applications you can trust what they're giving you. Sure, Amazon isn't going to ask the client how much an iPad costs and WoW isn't going to ask the client for the player's stats, but why should an application like Facebook care to verify whether you want to modify your own settings or send a friend request / wall post / whatever? If you attempt to perform an unexpected action (say, post to the wall of someone who's blocked you), the other user's client application logic (which is beyond your control) can still handle the junk data gracefully and simply. Also, later on (when you have more developer time to spare), if you want to for whatever reason, you can easily just deploy a server-side "garbage collector" of sorts to regularly clean up the database without disrupting client-side flow. It's not something you bolt on later. It can be, provided that it's only in the form of new features rather than fixing something which was insecurely implemented to start with. (For example, maybe the MVP is free but the next iteration is freemium and requires server-side price validation.)

bonaldi 15y ago
I shouldn't trust a hashed username and password? How are server-based systems more secure? How are you going to verify the password without a server? Passwords are a server-based system. That's a non-issue if it's handled by ACLs on the server. ACLs fine-grained enough to handle modern security scenarios are going to be just as complex as doing traditional validation. Any non-trivial sites are quickly going to get way more complex than just doing it the old-fashioned way. So why bother? why should an application like Facebook care to verify whether you want to modify your own settings or send a friend request? Because privacy is mission-critical for Facebook, and an exploit that allows me to send a friend request to myself as you is an unmitigated disaster for them. And trivial to do in a mostly-client world. Beyond trivial if I have access to the other client, which I am one browser bug or open wifi access point away from having. It can be, provided that it's only in the form of new features And those new features are going to be written in what? Since your MVP's framework doesn't support server-side logic, you're now splitting your code in three. Now you're either in maintenance or rewrite hell, just as you're taking off. That's not one of the good problems to have, it's one of the stupid problems you should have avoided by laying the right foundations at the start.
- buu700 15y ago
  How are you going to verify the password without a server? Only a dreadfully insecure system would choose to compare plain text passwords over the standard practice of hashing. It makes no difference if the hash is done client-side or server-side; if anything, even with SSL it's more secure to keep the plain text password removed from the network. ACLs fine-grained enough to handle modern security scenarios are going to be just as complex as doing traditional validation. How so? If I can manage my Facebook privacy settings graphically, any developer can manage ACLs in a DB schema graphically. No reason to unnecessarily clutter up code and deal with pointless architectural issues. Because privacy is mission-critical for Facebook, and an exploit that allows me to send a friend request to myself as you is an unmitigated disaster for them. And trivial to do in a mostly-client world. Beyond trivial if I have access to the other client, which I am one browser bug or open wifi access point away from having. Uh, what? If you have access to someone else's account then the game is already lost; no backend can solve that. Since your MVP's framework doesn't support server-side logic, you're now splitting your code in three. Now you're either in maintenance or rewrite hell, just as you're taking off. ...What? Who says whatever framework I use won't support server-side logic? Even vanilla JavaScript or jQuery is fine for AJAX calls. Not sure where you're getting "rewrite hell" from, but you must really hate the client APIs provided by Google, Yahoo, Facebook, and Microsoft.
  - bonaldi 15y ago
    over the standard practice of hashing A hash (like a plain password) is just a meaningless string unless you have something to compare it to. That means you have to store a trusted version elsewhere. Eg: a server. any developer can manage ACLs in a DB schema graphically And the client?. When I as user make you admin of my facebook event, how do I do it? Can my client side code change the access for other users? That might be, y'know, bad. Exploitable. Uh, what? If you have access to someone else's account then the game is already lost; no backend can solve that. Not access to someone else's account, just access to the other client via the network, browser bugs, bad proxies etc. It's a whole flock of blacksheep. There is a world of XSS that is only stopped by having wary, untrusting servers. Who says whatever framework I use won't support server-side logic Hi. This is a thread about Fireball, which is a new BaaS, one that promises no server-side logic. You appear to be defending this idea. Now I wonder if you understand it. We are not just talking about "some code running in the client". If you want to say client side code is fine so long as you have server-side logic for sanity checking, well, yes. Yes, it is. That's my point.