4 ms·

Am I missing something here? Just because you can request data and functionality from the client doesn't mean you'll get said data or functionality. On Meteor

Am I missing something here? Just because you can request data and functionality from the client doesn't mean you'll get said data or functionality. On Meteor the database API is the same on client and server, but that's just an API. A Mongo command on the client doesn't go directly to MongoDB on the server. You could have an access layer (or controller) on the server thru which all client requests are passed. And this access layer determines which client requests are relayed to the database. It seems to me the question isn't whether Meteor/Firebase can be made secure, but which implementation would be best for client responsiveness, developer effort etc.

bonaldi 15y ago
You're missing that the pitch with Fireball at least is there is no server code as such. To which everyone is pointing out "what about the business logic and validation?". The answers so far seem to be "we'll come up with, er, something in future" and "Microsoft Office is all client-side". EDIT: To clarify I'm not talking about Meteor here.
- geoffschmidt 15y ago
  That's not part of the pitch for Meteor. Take a look at point 6 on the Meteor homepage: Sensitive code runs in a privileged environment: Write all of your code in JavaScript (if you want.) The user interface runs in your browser. The sensitive functions run in a privileged server environment.
- Lazare 15y ago
  That's simply untrue, at least as far as Meteor goes. One of their big selling points is, in fact, that there IS server code.
- eaurouge 15y ago
  You're missing that the pitch with these things is there is no server code as such. For Firebase, yes that is part of the pitch. Personally the use case for Firebase doesn't really appeal to me. For Meteor, it's the opposite. The fact that you can write some server-only code is a plus.
marcusf 15y ago
Yup, seems like the hype took peoples common sense with it out the window. I'd assume and hope that just because there's a mongo api on the client, surely doesn't mean it's the raw socket that's exposed?
- geoffschmidt 15y ago
  The way it works in Meteor is, there is a data cache on the client with a Mongo-compatible API. When you type commands in the browser console, you're not hitting the real Mongo database at all, you're hitting that client-side cache. That's why it can be synchronous. When you do a write, it also does a RPC to the server to ask the server to do the same write. The server can accept the request, reject it, or do something totally different. Whatever ends up happening, the client cache is patched to reflect the results.
  - jcoffey 15y ago
    Geoff, a bit off topic here but do you have any comment on the GPL licensing/linking conversation people have been getting their nickers in a twist about every time meteor comes up on HN?
    - geoffschmidt 15y ago
      We've been working very hard on this, and are scrambling to digest all of the (stunningly helpful and specific) feedback and to educate ourselves. This thread isn't a good place for it, but we'll get something out soon.
  - chrisbroadfoot 15y ago
    Geoff, Does this mean the entire dataset is sent to the client?
    - geoffschmidt 15y ago
      You have a choice. If the "autopublish" package is added to your project, which it is by default, then the entire dataset is sent to the client. That's good for learning and prototyping, but isn't any good for production use. The Leaderboard example uses autopublish. Once you app works and you're ready to lock it down and scale it up -- and only then -- you remove the autopublish package. Now, it's up to you to define what's sent to the client. Use Meteor.publish() on the server to set up different datasets that clients are allowed to subscribe to, and use Meteor.subscribe() on the client to turn on/off a particular dataset. The Todos example demonstrates this -- it retrieves just the items for the todo list you're looking at, plus the list of lists. It's just a couple of lines of code, like 5 or 10, and not tricky ones either.
tg3 15y ago
I guess the long form of the question I'm asking is, "Can Meteor/Firebase be secure without adding back in a lot of the server-side effort that they were built to avoid." Avoiding the server-side seems to be a central part of Firebase's pitch, but as you say, you have to have a separate access layer through which your clients pass their requests. Who designs what the access layer looks like? Doesn't that require that you set up your users' accounts in a Firebase specific way so that they can have appropriate permissions in the access layer (which is server-side, by definition)? And that's only considering actual authorization to change data on the server. One of the comments below mentions business logic that shouldn't be tampered with, like discounts. How can any business logic at all be entrusted to the client to perform?
- eaurouge 15y ago
  I don't think it's right to lump Meteor and Firebase together as you've done here. They are similar and the sets of problems they aim to solve may overlap. But Firebase is a "scalable backend for your web app" and Meteor "is a set of technologies for building web apps". Firebase is more like a platform and Meteor is more like a framework, or SDK if you like. If you want to get a web app up and running quickly without having to build a backend, Firebase would be an option. With Meteor, one advantage is that you can write your client code as if you were building a desktop app, i.e. with minimal context switching. You can imagine the database is local and that any methods you call on the server are like calls to a local library with a well-defined API. Meteor would provide the glue between client and server that allows you to do this. Regarding your question: "Can Meteor/Firebase be secure without adding back in a lot of the server-side effort that they were built to avoid?" I think the Firebase founder commented somewhere on this post on how they might do this. But for Meteor, (1) I don't think the goal is merely to reduce server-side effort (2), I expect Meteor would provide much of this out of the box and you wouldn't have to do more on the server than you would with say Express or Rails.
  - tg3 15y ago
    You're right, I probably shouldn't have lumped them together. My question is probably more applicable to Firebase since they explicitly state that a goal is to eliminate servers (or at least make them optional).

bonaldi 15y ago

You're missing that the pitch with Fireball at least is there is no server code as such. To which everyone is pointing out "what about the business logic and validation?". The answers so far seem to be "we'll come up with, er, something in future" and "Microsoft Office is all client-side". EDIT: To clarify I'm not talking about Meteor here.

geoffschmidt 15y ago
That's not part of the pitch for Meteor. Take a look at point 6 on the Meteor homepage: Sensitive code runs in a privileged environment: Write all of your code in JavaScript (if you want.) The user interface runs in your browser. The sensitive functions run in a privileged server environment.
Lazare 15y ago
That's simply untrue, at least as far as Meteor goes. One of their big selling points is, in fact, that there IS server code.
eaurouge 15y ago
You're missing that the pitch with these things is there is no server code as such. For Firebase, yes that is part of the pitch. Personally the use case for Firebase doesn't really appeal to me. For Meteor, it's the opposite. The fact that you can write some server-only code is a plus.

marcusf 15y ago

Yup, seems like the hype took peoples common sense with it out the window. I'd assume and hope that just because there's a mongo api on the client, surely doesn't mean it's the raw socket that's exposed?

geoffschmidt 15y ago
The way it works in Meteor is, there is a data cache on the client with a Mongo-compatible API. When you type commands in the browser console, you're not hitting the real Mongo database at all, you're hitting that client-side cache. That's why it can be synchronous. When you do a write, it also does a RPC to the server to ask the server to do the same write. The server can accept the request, reject it, or do something totally different. Whatever ends up happening, the client cache is patched to reflect the results.
- jcoffey 15y ago
  Geoff, a bit off topic here but do you have any comment on the GPL licensing/linking conversation people have been getting their nickers in a twist about every time meteor comes up on HN?
  - geoffschmidt 15y ago
    We've been working very hard on this, and are scrambling to digest all of the (stunningly helpful and specific) feedback and to educate ourselves. This thread isn't a good place for it, but we'll get something out soon.
- chrisbroadfoot 15y ago
  Geoff, Does this mean the entire dataset is sent to the client?
  - geoffschmidt 15y ago
    You have a choice. If the "autopublish" package is added to your project, which it is by default, then the entire dataset is sent to the client. That's good for learning and prototyping, but isn't any good for production use. The Leaderboard example uses autopublish. Once you app works and you're ready to lock it down and scale it up -- and only then -- you remove the autopublish package. Now, it's up to you to define what's sent to the client. Use Meteor.publish() on the server to set up different datasets that clients are allowed to subscribe to, and use Meteor.subscribe() on the client to turn on/off a particular dataset. The Todos example demonstrates this -- it retrieves just the items for the todo list you're looking at, plus the list of lists. It's just a couple of lines of code, like 5 or 10, and not tricky ones either.

tg3 15y ago

I guess the long form of the question I'm asking is, "Can Meteor/Firebase be secure without adding back in a lot of the server-side effort that they were built to avoid." Avoiding the server-side seems to be a central part of Firebase's pitch, but as you say, you have to have a separate access layer through which your clients pass their requests. Who designs what the access layer looks like? Doesn't that require that you set up your users' accounts in a Firebase specific way so that they can have appropriate permissions in the access layer (which is server-side, by definition)? And that's only considering actual authorization to change data on the server. One of the comments below mentions business logic that shouldn't be tampered with, like discounts. How can any business logic at all be entrusted to the client to perform?

eaurouge 15y ago
I don't think it's right to lump Meteor and Firebase together as you've done here. They are similar and the sets of problems they aim to solve may overlap. But Firebase is a "scalable backend for your web app" and Meteor "is a set of technologies for building web apps". Firebase is more like a platform and Meteor is more like a framework, or SDK if you like. If you want to get a web app up and running quickly without having to build a backend, Firebase would be an option. With Meteor, one advantage is that you can write your client code as if you were building a desktop app, i.e. with minimal context switching. You can imagine the database is local and that any methods you call on the server are like calls to a local library with a well-defined API. Meteor would provide the glue between client and server that allows you to do this. Regarding your question: "Can Meteor/Firebase be secure without adding back in a lot of the server-side effort that they were built to avoid?" I think the Firebase founder commented somewhere on this post on how they might do this. But for Meteor, (1) I don't think the goal is merely to reduce server-side effort (2), I expect Meteor would provide much of this out of the box and you wouldn't have to do more on the server than you would with say Express or Rails.
- tg3 15y ago
  You're right, I probably shouldn't have lumped them together. My question is probably more applicable to Firebase since they explicitly state that a goal is to eliminate servers (or at least make them optional).