5 ms·

The issue is bigger: All of the business logic is on the client side. You will, eventually, have to move some of the logic to the server side. I'm sure that

by Void_ 15y ago

The issue is bigger: All of the business logic is on the client side. You will, eventually, have to move some of the logic to the server side. I'm sure that it is/will be possible with Meteor/Firebase, but it's not as easy as writing a Rails app.

mayop100 15y ago
Actually, no, you won't. Before SaaS apps, all applications were client side. Microsoft Office, for instance, is a fully client-side application.
- bonaldi 15y ago
  ... And, setting aside that Office is compiled, Office stores its files locally. When then those files move to shared space like servers, those servers get their own authentication and controls. Unless you're really saying the Firebase can only be used securely for client apps that live entirely on the client and don't need a server at all? I hope not. I was very interested to see what the answer is here, but the answers from the team didn't give me confidence that there is one, or that they were treating the problem with enough gravity. Then I see answers like this one, which give me the fear. Business logic that clients can access and change isn't a security hole, it's a security catastrophe. Until it can be protected, you can't build anything more than toys with this.
  - mayop100 15y ago
    Security for the data in Firebase is one issue - and as I've mentioned above we're taking that very seriously, and we're working on it. The business implications of having client-side software are a different issue, and I think its been demonstrated many times that businesses can do very well even with most or all of their code running client-side. Any desktop / mobile software works like this, as I mentioned. Relying on a compiler for security is a bad idea, just as you shouldn't rely on people not messing with your javascript. Clients today can access and change MS Office if they know what they are doing.
    - bonaldi 15y ago
      Yes, but virtually the only business logic in traditional Office is in the licensing, which has been repeatedly cracked. You're not really comparing like with like here, unless you're saying that Firebase will solely be used for making non-networked "tool" apps. If you're talking about networked apps, then, no, they havent always been client side. They started as tty/3270-esque apps and grew from there, with the business logic staying on the server and the clients growing in capability and power. Boil it down: there are rules that say only managers can change vacation days, or that govern where and when discounts are applied, or who can upvote a comment, or what the power up bonus is, or whether even to check for any of these things. If these things live in the client, how are they secured from interference?
      - buu700 15y ago
        If these things live in the client, how are they secured from interference? It doesn't sound like he's implied that this could be manipulated by the client at all; in fact, he's explicitly implied the opposite. Why would ACL definitions have to live in code (as opposed to, say, a simple Web interface)? I'd think something as simple as a graphical UI to define database schemata with read/create/modify permissions for owner/world on each field would be enough to cover 82% of use cases effectively. Beyond that (e.g. complex group management), I can't think of a secure client-side solution off the top of my head, but I suppose that would be what the Node.js plugin could be used for. Edit: Actually, for a lot of use cases group management could be handled by the client as well. For example, if a group is defined by a table, then the creator/owner is de facto the first member and administrator. If any administrative actions require an admin auth key and adding new members or admins is an administrative action, then there really isn't any way to hack the system. (I assume a user's auth key could just be something like a client-side hash of their username and password.)
        bonaldi 15y ago
        Security needs less implications and more explicit answers. Besides, there is more to business logic than simple (or complex) access control. More than one Facebook game has discovered to their cost the problems of trusting the score the client is sending to you. Or take discounts: if I want to give 10% off for orders over £20, where does that rule live? If it's on the client, well, what stops the client changing that to 90% off? Perhaps you ACL the order table and only allow access to a non-client facing instance. The client sends an order to that, which verifies it and sends it on if approved? Well, fine, but that's a server, and one of the main pitches here is "No servers! No server code."
geoffschmidt 15y ago
Meteor apps have both a client side and a server side. That's why you use 'meteor bundle' to bundle up your app, instead of just ftp'ing the source to the server. For the business logic that needs to be secure, you put it on the server using Meteor.methods() and Meteor.call(). You still get all the Meteor features like automatic distributed page updates and latency compensation. EDIT: sorry, didn't catch the "is/will be"

by Void_ 15y ago

mayop100 15y ago

Actually, no, you won't. Before SaaS apps, all applications were client side. Microsoft Office, for instance, is a fully client-side application.

bonaldi 15y ago
... And, setting aside that Office is compiled, Office stores its files locally. When then those files move to shared space like servers, those servers get their own authentication and controls. Unless you're really saying the Firebase can only be used securely for client apps that live entirely on the client and don't need a server at all? I hope not. I was very interested to see what the answer is here, but the answers from the team didn't give me confidence that there is one, or that they were treating the problem with enough gravity. Then I see answers like this one, which give me the fear. Business logic that clients can access and change isn't a security hole, it's a security catastrophe. Until it can be protected, you can't build anything more than toys with this.
- mayop100 15y ago
  Security for the data in Firebase is one issue - and as I've mentioned above we're taking that very seriously, and we're working on it. The business implications of having client-side software are a different issue, and I think its been demonstrated many times that businesses can do very well even with most or all of their code running client-side. Any desktop / mobile software works like this, as I mentioned. Relying on a compiler for security is a bad idea, just as you shouldn't rely on people not messing with your javascript. Clients today can access and change MS Office if they know what they are doing.
  - bonaldi 15y ago
    Yes, but virtually the only business logic in traditional Office is in the licensing, which has been repeatedly cracked. You're not really comparing like with like here, unless you're saying that Firebase will solely be used for making non-networked "tool" apps. If you're talking about networked apps, then, no, they havent always been client side. They started as tty/3270-esque apps and grew from there, with the business logic staying on the server and the clients growing in capability and power. Boil it down: there are rules that say only managers can change vacation days, or that govern where and when discounts are applied, or who can upvote a comment, or what the power up bonus is, or whether even to check for any of these things. If these things live in the client, how are they secured from interference?
    - buu700 15y ago
      If these things live in the client, how are they secured from interference? It doesn't sound like he's implied that this could be manipulated by the client at all; in fact, he's explicitly implied the opposite. Why would ACL definitions have to live in code (as opposed to, say, a simple Web interface)? I'd think something as simple as a graphical UI to define database schemata with read/create/modify permissions for owner/world on each field would be enough to cover 82% of use cases effectively. Beyond that (e.g. complex group management), I can't think of a secure client-side solution off the top of my head, but I suppose that would be what the Node.js plugin could be used for. Edit: Actually, for a lot of use cases group management could be handled by the client as well. For example, if a group is defined by a table, then the creator/owner is de facto the first member and administrator. If any administrative actions require an admin auth key and adding new members or admins is an administrative action, then there really isn't any way to hack the system. (I assume a user's auth key could just be something like a client-side hash of their username and password.)
      - bonaldi 15y ago
        Security needs less implications and more explicit answers. Besides, there is more to business logic than simple (or complex) access control. More than one Facebook game has discovered to their cost the problems of trusting the score the client is sending to you. Or take discounts: if I want to give 10% off for orders over £20, where does that rule live? If it's on the client, well, what stops the client changing that to 90% off? Perhaps you ACL the order table and only allow access to a non-client facing instance. The client sends an order to that, which verifies it and sends it on if approved? Well, fine, but that's a server, and one of the main pitches here is "No servers! No server code."

geoffschmidt 15y ago

Meteor apps have both a client side and a server side. That's why you use 'meteor bundle' to bundle up your app, instead of just ftp'ing the source to the server. For the business logic that needs to be secure, you put it on the server using Meteor.methods() and Meteor.call(). You still get all the Meteor features like automatic distributed page updates and latency compensation. EDIT: sorry, didn't catch the "is/will be"