3 ms·

More importantly, how do I keep clients from fucking up my database? How is security being done? Seriously, if I'm not capable of baking limitations into data

More importantly, how do I keep clients from fucking up my database? How is security being done? Seriously, if I'm not capable of baking limitations into data persistence/logic at the server level then this entire framework is worthless except for building up a portfolio of cute demos that can't be used for any real work.

dmix 15y ago
As this question comes up every single time Meteor or Firebase is brought up, I think its fair to say that "we're working on it" wasn't and isn't a good enough answer.
- hbbio 15y ago
  You should also have a quick look there: http://news.ycombinator.com/item?id=3858838 http://news.ycombinator.com/item?id=3858838
analog 15y ago
From their newsletter which just went out, can't find a link online. "Please make sure it's reasonably secure. Meteor security isn't as hard as people think. Admittedly it doesn't yet have the delicious "candy coating" that the database and DOM update stuff has, but we didn't, like, forget to put any in. Here's what Made With does: * Use Meteor.publish() and Meteor.subscribe() to control what clients can see (remove the 'autopublish' package first). Actually you may not need to do this for a blog. * Use Meteor.methods() and Meteor.call() to define secure server functions and call them from the client. Then lock down your app by disabling the "training wheel" methods that let any client do any write." Also from a quick skim of the server code itself it looks like they are using connect, so you it's possible that you could roll something up using a connect middleware package like everyauth. [1] That would mean hosting your own server though rather than using the simple meteor deploy. [1] http://everyauth.com/ http://everyauth.com/
- heretohelp 15y ago
  >* Use Meteor.publish() and Meteor.subscribe() to control what clients can see (remove the 'autopublish' package first). Actually you may not need to do this for a blog. Scoping isn't enough. >* Use Meteor.methods() and Meteor.call() to define secure server functions and call them from the client. Then lock down your app by disabling the "training wheel" methods that let any client do any write." So, I can't make a production-grade app unless I use 0% of the magic.
  - foolinator 15y ago
    You're absolutely right. But all frameworks have to go through these humps. Hell, I remember just 2 years ago having MongoDB in production it would regularly crash. We got rid of it in production, but I'd reconsider using it now.
    - StavrosK 15y ago
      Which features, are making you consider MongoDB? I'm asking because I wrote a (really short and small) MongoDB-ish abstraction layer over SQLite the other day (https://github.com/stochastic-technologies/goatfish https://github.com/stochastic-technologies/goatfish), and it seems to me that it's trivial to emulate the MongoDB queries and various other features over SQL without all the hassle of it eating your data or requiring 100 GB of RAM for a few indices.
tjogin 15y ago
Reading the documentation would be good start.

dmix 15y ago

As this question comes up every single time Meteor or Firebase is brought up, I think its fair to say that "we're working on it" wasn't and isn't a good enough answer.

hbbio 15y ago
You should also have a quick look there: http://news.ycombinator.com/item?id=3858838 http://news.ycombinator.com/item?id=3858838

analog 15y ago

From their newsletter which just went out, can't find a link online. "Please make sure it's reasonably secure. Meteor security isn't as hard as people think. Admittedly it doesn't yet have the delicious "candy coating" that the database and DOM update stuff has, but we didn't, like, forget to put any in. Here's what Made With does: * Use Meteor.publish() and Meteor.subscribe() to control what clients can see (remove the 'autopublish' package first). Actually you may not need to do this for a blog. * Use Meteor.methods() and Meteor.call() to define secure server functions and call them from the client. Then lock down your app by disabling the "training wheel" methods that let any client do any write." Also from a quick skim of the server code itself it looks like they are using connect, so you it's possible that you could roll something up using a connect middleware package like everyauth. [1] That would mean hosting your own server though rather than using the simple meteor deploy. [1] http://everyauth.com/ http://everyauth.com/

heretohelp 15y ago
>* Use Meteor.publish() and Meteor.subscribe() to control what clients can see (remove the 'autopublish' package first). Actually you may not need to do this for a blog. Scoping isn't enough. >* Use Meteor.methods() and Meteor.call() to define secure server functions and call them from the client. Then lock down your app by disabling the "training wheel" methods that let any client do any write." So, I can't make a production-grade app unless I use 0% of the magic.
- foolinator 15y ago
  You're absolutely right. But all frameworks have to go through these humps. Hell, I remember just 2 years ago having MongoDB in production it would regularly crash. We got rid of it in production, but I'd reconsider using it now.
  - StavrosK 15y ago
    Which features, are making you consider MongoDB? I'm asking because I wrote a (really short and small) MongoDB-ish abstraction layer over SQLite the other day (https://github.com/stochastic-technologies/goatfish https://github.com/stochastic-technologies/goatfish), and it seems to me that it's trivial to emulate the MongoDB queries and various other features over SQL without all the hassle of it eating your data or requiring 100 GB of RAM for a few indices.

tjogin 15y ago

Reading the documentation would be good start.