4 ms·

This is great news. One thing I can't get my head around, I actually spent some time yesterday evaluating using Firebase, cloned the FireFeed demo app and brow

This is great news. One thing I can't get my head around, I actually spent some time yesterday evaluating using Firebase, cloned the FireFeed demo app and browsed it, but I still have one thing I guess I'm missing completely. Can someone explain this: is there any way to have a secure app with only HTML JS and no back end at all? I assume you must at least have something on the server to add your secret key, right? Or is there some magic way to ensure no one else is writing or reading to/from your Firebase acount. I'm sure it's documented, but if it does, it's not that clear to me, seems there has to be at least one small server layer for you to make it really work, did I miss something?.

RyanZAG 14y ago
I had this exact same question when I saw it. This is handled by Security Rules [1]. You define these rules using JSON - basically read/write access to objects on a per-user basis. Seems like a good solution, depending on how flexible the validation style rules are (seem to be very flexible at a glance). I'm pretty impressed by the product, looks like it may even be a game changer for doing quick web apps. [1] https://www.firebase.com/docs/security/security-rules.html https://www.firebase.com/docs/security/security-rules.html
mikelehen 14y ago
Great question! The key to our security model is our Security Rules system. Security rules are authored by the developer and stored as part of their Firebase. Firebase then executes them automatically to validate all reads and writes of data. You can check out the rules for Firefeed here: https://github.com/firebase/firefeed/blob/master/rules.json https://github.com/firebase/firefeed/blob/master/rules.json And be sure to check out our Security Quickstart Screencast, walking you through the system: https://www.firebase.com/docs/security-quickstart.html https://www.firebase.com/docs/security-quickstart.html
- derefr 14y ago
  For anyone who isn't clear on what exactly this entails, but have some experience with AWS: it's a bit [a lot] like S3 bucket policies.
- eranation 14y ago
  The Security Quickstart Screencast is superb, thanks!
- eranation 14y ago
  Few more questions if I may: 1) indexing, didn't see any options, I assume it's planned in the future along with more complex query language? 2) self register as a RequireJS / AMD module, is this planned? Again, this is great. thanks
  - mikelehen 14y ago
    1. The API was designed pretty carefully to ensure we wouldn't box ourselves into any corners that would limit our real-time or scalability capabilities. So we've intentionally avoided advanced querying for now. You may see features along these lines in the future, but right now we recommend denormalizing your data during writes to match how you want to consume the data (which is a pretty common nosql practice). Firefeed is a good example of this, actually. 2. RequireJS is on our radar. I don't know too much about it, but if developers want it, we'll likely end up adding it. :-)
    - tristanz 14y ago
      On the denormalization front, is it possible to do transactions without locking / syncing the entire tree. I'm thinking friendship modeling like: user1.friends = ['user2'] user2.friends = ['user1']
      - mikelehen 14y ago
        Transactions have to be done at the common ancestor of the data being modified, so it's best to use them for data that's nearby in the Firebase data tree. You /can/ do a transaction on a large chunk of data (e.g. the entire user list), but the client would need to sync the entire data and there'd be a greater chance of contention. If you need atomic bidirectional friendships though, you can do it if you structure your data a little differently. To turn a friendship between a pair of users on and off, you could set /friends/user1/user2 to true iff user1 and user2 are friends. Then you can write security rules that are based off of that to allow and deny access to the users' data.
    - eranation 14y ago
      Regarding #2, to register as a module you just need something like this: https://github.com/umdjs/umd/blob/master/amdWeb.js https://github.com/umdjs/umd/blob/master/amdWeb.js

RyanZAG 14y ago

I had this exact same question when I saw it. This is handled by Security Rules [1]. You define these rules using JSON - basically read/write access to objects on a per-user basis. Seems like a good solution, depending on how flexible the validation style rules are (seem to be very flexible at a glance). I'm pretty impressed by the product, looks like it may even be a game changer for doing quick web apps. [1] https://www.firebase.com/docs/security/security-rules.html https://www.firebase.com/docs/security/security-rules.html

mikelehen 14y ago

Great question! The key to our security model is our Security Rules system. Security rules are authored by the developer and stored as part of their Firebase. Firebase then executes them automatically to validate all reads and writes of data. You can check out the rules for Firefeed here: https://github.com/firebase/firefeed/blob/master/rules.json https://github.com/firebase/firefeed/blob/master/rules.json And be sure to check out our Security Quickstart Screencast, walking you through the system: https://www.firebase.com/docs/security-quickstart.html https://www.firebase.com/docs/security-quickstart.html

derefr 14y ago
For anyone who isn't clear on what exactly this entails, but have some experience with AWS: it's a bit [a lot] like S3 bucket policies.
eranation 14y ago
The Security Quickstart Screencast is superb, thanks!
eranation 14y ago
Few more questions if I may: 1) indexing, didn't see any options, I assume it's planned in the future along with more complex query language? 2) self register as a RequireJS / AMD module, is this planned? Again, this is great. thanks
- mikelehen 14y ago
  1. The API was designed pretty carefully to ensure we wouldn't box ourselves into any corners that would limit our real-time or scalability capabilities. So we've intentionally avoided advanced querying for now. You may see features along these lines in the future, but right now we recommend denormalizing your data during writes to match how you want to consume the data (which is a pretty common nosql practice). Firefeed is a good example of this, actually. 2. RequireJS is on our radar. I don't know too much about it, but if developers want it, we'll likely end up adding it. :-)
  - tristanz 14y ago
    On the denormalization front, is it possible to do transactions without locking / syncing the entire tree. I'm thinking friendship modeling like: user1.friends = ['user2'] user2.friends = ['user1']
    - mikelehen 14y ago
      Transactions have to be done at the common ancestor of the data being modified, so it's best to use them for data that's nearby in the Firebase data tree. You /can/ do a transaction on a large chunk of data (e.g. the entire user list), but the client would need to sync the entire data and there'd be a greater chance of contention. If you need atomic bidirectional friendships though, you can do it if you structure your data a little differently. To turn a friendship between a pair of users on and off, you could set /friends/user1/user2 to true iff user1 and user2 are friends. Then you can write security rules that are based off of that to allow and deny access to the users' data.
  - eranation 14y ago
    Regarding #2, to register as a module you just need something like this: https://github.com/umdjs/umd/blob/master/amdWeb.js https://github.com/umdjs/umd/blob/master/amdWeb.js