4 ms·

Another great step in the right direction. That being said, I do believe the hardest part of all these attempts to abstract backends is authentication and secu

Another great step in the right direction. That being said, I do believe the hardest part of all these attempts to abstract backends is authentication and security models. It seems to me that most of these services launch before figuring out that critical part of the puzzle.

nicholasreed 15y ago
We're using authentication in our Firebase app and it works wonderfully. Although all data is visible on the Firebase backend, we simply put pointer ids in Firebase, so no identifying data is publicly visible.
- arturadib 15y ago
  Care to elaborate? Firebase's FAQ seems to suggest that they're still working on a solution.
  - nicholasreed 15y ago
    I believe they are working on a fully documented and stable auth solution; we're running something custom for now. Our whole Firebase namespace is read-only, so all our writing happens with a private key from our server. I think when the Firebase admin panel has more protection we can store more sensitive/identifiable data in there.
- skarayan 15y ago
  What level of control do you have for authentication? I didn't see much info on this on the website.
  - nicholasreed 15y ago
    Write control was most important for us; all the readable data are simply id's to our internal DB
geoffschmidt 15y ago
Meteor dev here. You're absolutely right that authentication is one of the hardest parts. What's happening is that the web is moving from a model analogous to mainframes and dumb terminals (where there is a central authority directly driving everyone's screens), to a distributed model where there are a lot of different actors, with different levels of trust for each other. Figuring this stuff out is hard. Usually for questions that come up in this shift, we have a good model we can look at, which is the client/server desktop applications of the late 80s and early 90s. But in the case of authentication and security, they tell us not so much, because in those days most software lived inside private corporate silos. These days, our software not just technologically distributed, it's politically distributed. In the case of Meteor, it's designed from the ground up for security. In fact, it's a second generation security model, designed after reflecting on lessons learned from Asana's Luna platform (I worked on Luna at Asana for a while in 2010.) It just isn't exposed in a user-friendly way in the Tuesday release. But people dug into the code, found it, and are using it anyway, whether we like it or not. Briefly, 'meteor remove autopublish', use Meteor.publish to define what data clients can access, use Meteor.subscribe to control what data a particular client is getting, use Meteor.methods to define what writes clients can do, and see the following Stack Overflow question to disable the 'newbie mode' insert()/update()/remove() that let you do arbitrary writes to the database. http://stackoverflow.com/questions/10115042/how-do-you-secure-the-client-side-mongodb-api http://stackoverflow.com/questions/10115042/how-do-you-secur...

nicholasreed 15y ago

We're using authentication in our Firebase app and it works wonderfully. Although all data is visible on the Firebase backend, we simply put pointer ids in Firebase, so no identifying data is publicly visible.

arturadib 15y ago
Care to elaborate? Firebase's FAQ seems to suggest that they're still working on a solution.
- nicholasreed 15y ago
  I believe they are working on a fully documented and stable auth solution; we're running something custom for now. Our whole Firebase namespace is read-only, so all our writing happens with a private key from our server. I think when the Firebase admin panel has more protection we can store more sensitive/identifiable data in there.
skarayan 15y ago
What level of control do you have for authentication? I didn't see much info on this on the website.
- nicholasreed 15y ago
  Write control was most important for us; all the readable data are simply id's to our internal DB

geoffschmidt 15y ago

Meteor dev here. You're absolutely right that authentication is one of the hardest parts. What's happening is that the web is moving from a model analogous to mainframes and dumb terminals (where there is a central authority directly driving everyone's screens), to a distributed model where there are a lot of different actors, with different levels of trust for each other. Figuring this stuff out is hard. Usually for questions that come up in this shift, we have a good model we can look at, which is the client/server desktop applications of the late 80s and early 90s. But in the case of authentication and security, they tell us not so much, because in those days most software lived inside private corporate silos. These days, our software not just technologically distributed, it's politically distributed. In the case of Meteor, it's designed from the ground up for security. In fact, it's a second generation security model, designed after reflecting on lessons learned from Asana's Luna platform (I worked on Luna at Asana for a while in 2010.) It just isn't exposed in a user-friendly way in the Tuesday release. But people dug into the code, found it, and are using it anyway, whether we like it or not. Briefly, 'meteor remove autopublish', use Meteor.publish to define what data clients can access, use Meteor.subscribe to control what data a particular client is getting, use Meteor.methods to define what writes clients can do, and see the following Stack Overflow question to disable the 'newbie mode' insert()/update()/remove() that let you do arbitrary writes to the database. http://stackoverflow.com/questions/10115042/how-do-you-secure-the-client-side-mongodb-api http://stackoverflow.com/questions/10115042/how-do-you-secur...