Skip to content
This repository has been archived by the owner on Dec 18, 2024. It is now read-only.

Authorization Middleware Possibilities for OrbitDB #76

Open
509dave16 opened this issue Jul 6, 2018 · 4 comments
Open

Authorization Middleware Possibilities for OrbitDB #76

509dave16 opened this issue Jul 6, 2018 · 4 comments

Comments

@509dave16
Copy link

My idea is still a work in progress so bear with me. At this point from what I have seen, key signing per each peer is how granting access to store data works in OrbitDB. I am hoping to introduce a finer grained level of access. And to do that I was thinking that creating a middleware would be a good option. The idea is that metadata stores could exist to map doc, key/val, etc.. access to different users. With that middleware in place, attempts could be denied/granted based on the metadata store. This is a very rough idea and may not be feasible though with the middleware alone. I may need to also use a 3rd party service(like uPort or Auth0) to handle the storage of this kind of information.

Appreciate any thoughts or direction people in community might have on this topic.
I know that work is being done on the Dynamic Access Controllers. But from my understanding that is access at a store level. I am hoping to make it possible to do it at a lower level.

@509dave16
Copy link
Author

The only syncing database that I know of that currently implements ACL is Realm:
https://docs.realm.io/platform/using-synced-realms/access-control

Hoping to find a way to mirror how they achieve ACL.

@fazo96
Copy link

fazo96 commented Aug 7, 2018

@509dave16 some work about this is happening here orbitdb-archive/ipfs-log#128

@509dave16
Copy link
Author

@fazo96 Thanks for the tip! Appreciate it.

@aphelionz
Copy link
Collaborator

Moving to Field Manual for deeper discussion

@aphelionz aphelionz transferred this issue from orbitdb/orbitdb Sep 27, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants