Authorization Wrapper

[metasean]

No description provided.

[amark]

In a decentralized, federated, or centralized context? IDK if we'll ever be answer this in GUN because we can't/don't know in advance who is authorizing what. Isn't this very app-business-logic specific? So I'm guessing maybe this just means having some boilerplate assumptiony frameworks for each of those 3 categories?

I think what we really need to think about and figure out... which will help clean up and organize all these issues into cleaner logic and required dependencies... is that so much of this stuff gets solved largely by having a schema system. So much that possibly a lot of these different issues could be resolved by them extending some base-schema enforcer. The priority/shard API issue - specified by a schema attribute? What data is encrypted (authentication) or who (authorization) is allowed to modify it - specified by a schema attribute? Etc.

[Xe]

This might be outside the realm of where gun should care.

[RangerMauve]

It'd be nice if there were hooks in the sync process that would allow one of the nodes to refuse an update being sent by another. For instance, if I know that this node I'm syncing with shouldn't have have write access to system/data/*, if it tries to send me updates to keys that match that pattern, I'd ignore them since it's behaving maliciously. It would probably be as simple as a hook that has the key name, maybe some sort of reference to the peer trying to do the update, and a callback for accepting or denying the update.

[amark]

@RangerMauve absolutely, agreed. If I can make the hook system well/correct enough then most authorization/authentication stuff like this would be easy. I'm afraid I'm going to do it wrong though, so when I get around to adding the feature you should help guide me/feedback. Any ideal API for it that you'd like to see?

Also, are you working on any project with gun yet? Anything I can do to help with it?

[RangerMauve]

@amark Firstly, there should be some way of identifying the peer that your synchronizing with in the hook so that one could have complex logic based around that (say, querying what that peer should be authorized to know from a central authority). Other than that it would really just be a hook for new nodes being added from the peer, and updates to nodes being received from the peer. Just having the keypath, the new node data / node updates, and some identifier for the peer and a callback that takes a boolean for whether to accept this change or not, would be good. Maybe also a hook for filtering what data can be sent to the peer, too, so that one could withhold data from certain peers.

Currently I don't really have a specific project using this, but I could see myself using this for some small test apps in the near future, and maybe building bigger things once this authorization stuff is figured out.

Another comment that might be better in a separate issue, is that the code itself doesn't seem to be making use of CommonJS in the best way possible. The client for example seems to just be one large file which makes it a bit harder to grasp, and the server seems to be conditionally looking for a global Gun variable which is bad practice. Other than that the project itself is really in tune with my ideals on what a DB should do so I've been really excited about it since I first saw it and can't wait to see how it'll change the way people make apps.

[amark]

@RangerMauve peer identification based on IP or domain is fine, yes? A related question, what if you are wanting to do rules based on some person and not an IP? Let's say Alice connects to the system via different providers (which are different peers), should she still be restricted because the security rules are peer based, not user based?

My plan for the hook is that it will basically give you the full HTTP (or HTTP normalized) request information, which will contain headers and cookies and all the good stuff. This way you aren't restricted in what you could do. Like you suggested, you could use that information to then check against a centralized authority.

The ability to approve/reject a sync, I like this. You also mention a filter system, I've been thinking about whitelist/blacklist behavior. My assumption is that this requires some sort of schema to exist, right? Which means building a schema system is a necessary requirement before a filter system can exist. Would you be interested in helping with this?

Thank you for the compliment!!! It is really encouraging. You are right, there is still a lot of work that needs to be done before it is ready for larger projects. I moved my comments about the CommonJS structure over to the other issue you opened at #87 . Thanks so much again!

[RangerMauve]

In terms of identifications, I think peers should have some sort of id that they derive themselves. Maybe it'd make sense to auto-generate a UUID by default and leave anything more complicated to the user of the library. For instance a certain application might want to just use something like a "user id" that they can send to everyone. Maybe others would want to have a session token that only a central authority could validate. Maybe someone would want to use their public key for some sort of encryption. Or likely it'd be something that I couldn't even think of at the moment. If it's treated as essentially a UUID, and there's the possibility of making it user defined, then it would support full flexibility for whoever wants to use it.

I think that the filter should really just be a function defined by whoever wants to use that functionality. I kinda like how there isn't an explicit schema in place other than the constraint of storing the soul of the nodes, and I think that it would be better to keep it that way. In terms of the filtering, I think the easiest thing to actual do for an implementer is just do some sort of regex on the key that's being updated, and maybe to inspect the content if they're that fancy.

I don't think you should tie yourself too much to a particular transport. It may be that in the future it would be useful to be able to run this over an arbitrary stream.

[amark]

@RangerMauve yes, I like what you describe better. This should be the goals of auth wrapper when we (or somebody else) gets around to it. Necessary for a stable release though.

There is one edge case though, because the data is graph based, a key is not tightly bound to a node UNLESS the app developer explicitly wants it to be (aka by using gun in a table based approach). Multiple keys can point to the same node, and traversing paths in a graph can also point to a node. So if your security is based off of key pattern then you might get denied access to a node if you try navigating to it through other keys or via a path, unless you already have the key itself.

[RangerMauve]

Well, I don't think that's too much of an issue. If you don't have access to something that a path is pointing at then you just shouldn't be able to traverse the path all the way

[amark]

@RangerMauve agreed. How are you doing?

[amark]

We already have some crypto examples, as well as the 1 minute explainer videos series on this now http://gun.js.org/explainers/data/security.html .

Plus I almost have a P2P crypto social network example I'll be publishing.

Anyways, because this is not a "bug" in gun, and we're quickly moving into v1.0 people should ask about this over at https://github.com/gundb/feature-requests . So that way it is easy for others to differentiate between "bugs" and non-issues. Closing for now! But don't worry this is super important and being worked on.