we too have authorization rules at the boundary, all commands and queries from clients are authorized… I think it’s common that authorization is based on a few core entities that are part of the query args / command payload
1➕Q: about creating a global datomic cloud service i.e. multi-regions. does anyone have experience with this? https://forum.datomic.com/t/replication-of-some-all-datoms-to-other-dbs/1779
Hey @steveb8n sorry I missed the post. I just updated on the forum thread as slack gets archived. I am just hoping to understand the problem space a little bit better before I jump into cross region advice/approaches.
@jaret thanks. I’ve replied there too. better for it to be in a permanent record for others.
that nubank presentation with filter was interesting, it would be to see actual performance numbers… it would seem to me that the filter approach can’t use indexes efficiently, but don’t know any details
Understanding question: If you pull an existing attribute (that isn’t :db/id
) of a non-existing entity, you get nil
, but if you pull :db/id
of that same non-existing entity, you get {:db/id nil}
. Why is that?
Thanks @tatut!
Being new to datomic this is quite an interesting problem for me.
The filter
solution (on-prem only!) seems to be very clean, and it’s what nubank are using. Query logic is separated from access restrictions.
Leveraging “database as a value” and thus playing to datomic strengths.
The other nice thing about datomic is ofc “queries are data” as mentioned by @lanejo01
I’ve just used this approach to write a boundary query-as-a-user fn, which rewrites the queries to refer to access restriction rule.
Somehow it doesn’t really feel right, less separate, less explicit. Maybe it’s just my shoddy impl 😜 We will see how it fares in practice! If anyone has examples of those kinds of things in real world (w/ users, permissions, auth etc) open source code I would love to see them! Cheers!
How complex is your permission model?
ATM I’m only concerned with the ~trivial case of: “Alice owns some resources and only Alice can see them” where resources are entity level, so not very complicated and not very granular, but that will probably evolve. It’s a knowledge base type of application so where this will potentially get more interesting is in the cross-sections of public and private information--private knowledge graphs embedded in public ones. So I’m just trying to model this in a nice way with datomic without prior experience with datomic ;)
Presently I was mainly concerned with the simple mechanics i.e. where those restrictions should sit (in terms of best practices), so it’s not error prone.
So today I’ve just added a rule and a centralised query fn for restricted resources that just adds those access constraints captured by the rule to the :where
clause... so far so good I think ;)