mikelehen

7 ms·

31.
by mikelehen 14y ago
Ooops. When the editor has focus, it tries to keep your cursor visible when it moves. And your cursor can end up moving due to other people's edits. I tweaked the page to not auto-focus the editor. Thanks!
32.
by mikelehen 14y ago
This should be a pretty easy thing to add, and it's all open source... :-)
33.
by mikelehen 14y ago
Yes! His work is great. Made for a great starting point for building Firepad. :-)
34.
by mikelehen 14y ago
Firepad will eventually support rich-text copy/paste and import/export as HTML (export is actually already supported through the API, but not exposed through the existing UI), as well as lists, paragraph indent, and all of the other feature
35.
by mikelehen 14y ago
We built it as a Firebase app, but we're releasing it as open source and are looking forward to seeing what the community does with it. :-) All of the OT work happens client-side, so it's certainly possible to adapt it to other backends. A
36.
by mikelehen 14y ago
I'm biased, since I'm a Firebase dev, but honestly, Firebase is great for solving /all kinds/ of use cases. :-) We've had people build everything from emergency response simulations synchronized across multiple devices to iOS apps for grand
37.
by 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
38.
by 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 t
39.
by mikelehen 14y ago
Absolutely. Our Node.JS Library[1] and REST endpoints[2] are for exactly that. So you can still keep all the benefits of Firebase (real-time data synchronization between all clients of your app) while augmenting it with server-side code spe
40.
by 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 da
41.
by mikelehen 14y ago
The Candle Plan is and will continue to be free! (All of the pricing on the website is just to give people an idea of what the pricing will be when we leave beta. It's not being enforced right now.)
42.
by mikelehen 14y ago
Firebase doesn't use cookies for authentication so CSRF isn't an issue. You have to explicitly call auth() on our JavaScript SDK with valid credentials, or include valid credentials in the querystring of a REST request.
43.
by mikelehen 14y ago
During the design process, we solicited feedback from several security experts (security firms and ad-hoc hackers alike). It hasn't gone through a formal outside audit at this point though. (And please do keep in mind that we're still a be
44.
by mikelehen 14y ago
Thanks! We're certainly grateful for all of the input and feedback we received while designing this thing (especially from our beta users who came through time and time again, giving us countless security use cases and providing feedback o
45.
by mikelehen 14y ago
Fay looks neat! I'll have to play with it. Since the whole rules language is custom, we're not using any off-the-shelf projects presently, and to be honest, we've only scratched the surface of what's possible. Most of what we have in place
46.
by mikelehen 14y ago
Here's a little secret. The security rules you, as a Firebase developer, write for your Firebase, are actually server-side validation code. It just doesn't look like typical code, and we've carefully designed them to have a lot of good pr
47.
by mikelehen 14y ago
This is where Security Rules shine over ACL's or other more rigid security models. As the application developer, you have complete control over that sort of functionality since the rules are quite flexible and have direct access to your Fi
48.
by mikelehen 14y ago
Yeah. That bugs us too. :-) We might support a non-JSON format for easier authoring at some point, but we thought JSON was the right starting point since people are familiar with it and it has a lot of good tooling and interoperability ad
49.
by mikelehen 14y ago
Michael from Firebase here. By using declarative rules instead of arbitrary code to enforce Security, we can do lots of optimization and guarantee predictable execution time (arbitrary code can take an arbitrarily long time to execute). I
50.
by mikelehen 15y ago
Hey. Yeah, we have an ACL system for specifying who can read/write data at each location. So you can lock down your application data to keep it secure. The API for this is still in flux though, so it's not documented. Coming soon though