Scoping, filtering, security about datsync HOT 2 OPEN

Did you watch the ClojureWest talk? I touched on this a bit there, but didn't go into details.

For read, the idea is to pass all transaction data through filters which embody the access control rules of the domain. The implementation of those filters can depend a bit on the specifics of the domain and rules granularity. But more or less, you need a function that either at the entity or datom level decides whether or not user x has access to datom/entity y, and decides which datoms to send to which clients based on that rule.

For write, things are fairly similar; define some functions which test for whether or not a given transaction is permissible based on the submitting user and the domain's access control model. Then either run that test before transacting, or actually run the test in a transaction function if you're access control model necessitates atomicity. The latter should probably be avoided when not necessary (and frequently I don't think it will be necessary), as it would put more work on the transactor (bottleneck).

My plan is to focus on this stuff more once datview has gotten to be a bit more stable. Then we'll have some more prepackaged functionality and dataflow, but for now just inlining those checks before sending out or transacting data is the ticket.

I know this is a pretty broad and general response, so let me know if you're already ahead of me, and whether there are more specific questions I can answer.

from datsync.

In terms of functions that would be run against reads and writes, are you talking about rules, or more manual functions that receive a query, parse and determine whether or not it should be allowed?

And as far as filtering, do you mean using filters, or was that in a more general sense?

from datsync.