-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Ask Purpose of Access Control on P2P Topic] #16
Comments
Well, yes, the implementation is different from the documentation. And yes, implementation is not great. The only permission which works as intended is 'P'. The rest should be fixed. |
Permissions have two sides: 'given' and 'want'. With P2P the original idea was for peers to set each other's 'given' permissions. But the mechanism to set the 'given' side for P2P topics is not implemented. Basically, it should work by user1 sending setMeta for user2 and vice versa. |
The key question is if it needs to be fixed now. |
Hmm, I see, so the original idea was each user in But I think we could make it simpler. What do you think if we just treat the permission in So for example there are In current implementation, if we create But if we treat So in this case, What do you think? |
Hmm…, I think it depends on your roadmap, Gene. But I found that this issue won’t affect the system basic functionality as long as both users in Btw, in current implementation I found that the default value for If you need some extra hand, I would gladly to participate 😃👍 |
Yes, that's the correct description of the current incorrect implementation. P2P's given is currently set to
I think there is a legitimate need for two sets of permissions, wanted and given. For instance, user1 may not want to accept connections from other users. So, user2 has to ask for access first: "user1, please give me permissions want". Then user1 would "approve" the request by setting given permissions. The
It should be |
If it creates problems then maybe I should just fix it. Since you are using it I would greatly appreciate your help with debugging. |
Hoo…, ok (y) So how does system supposed know that The reason why I'm asking this is because in current implementation, user’s default access define 'want' permission for this user to other user P2P topic, right? Not define 'given' permission for other user to access this user.
Hmm…, ok, I will try to debug it (y)
Sure, it’s an honor to be able to help you 😎👍 |
Yes,
Yes, that's how it's implemented now and that's not right. It should define given for the other user instead. Default want should be just the maximum possible value, for instance equal to given. I'll look into it over the weekend. |
JFYI, I'm working on this. It's just taking a bit longer than expected. |
Please take a look: #20 |
And tinode/webapp#7 |
Hello, Gene I noticed that you change I thought that in this new version we will be using default P2P access mode as permission
Why would current user give access to approve the newly established p2p connection to another user rather than itself? It should be current user which have the permission to approve the connection, right? Or maybe I misunderstood the permissions meaning? Thanks. |
Hi Riandy, A is intended as a topic administrator's permission. A is for Administrator. It's a permission which allows the A user to manage permissions of other subscribers of the given topic (P2P or Group). It seems appropriate for the case of P2P topics where each user manages permissions of the other user. The two participants of a P2P topic cannot invite other users to the topic because of the way the name of a P2P topic is composed. It's based on a concatenation of the IDs of the two participants. So the A permission will only affect the two members of the P2P topic. |
If I don't hear any objections in the next few hours I'm going to merge it to devel |
Hmm…, I see… But wouldn’t it better if Notice following scenario: For example there are user A & B which have Since user B doesn't have |
It is appended. Here: https://github.com/tinode/chat/blob/permissions/server/store/types/types.go#L291
That's not possible because user A will always have |
Hmm..., here are the steps which I'm using to generate above scenario where user could remove
So yes, it cannot remove Also notice that the
Hmm..., what I meant with append was we append the Notice that if the user having |
Good point, thanks. I'll fix that.
I'm still not sure what you mean here. The database has to be either updated or regenerated with the new permissions.
Yes, that's what I mean too. It should always have an
Correct, but the default access without an |
Ok, never mind for this one. Actually I got hint for this issue because I was using the old database which still contain user with previous permission model without updating it 😅.
Another scenario is when user specify
|
Thanks. Updated |
Merged into devel |
I have a similar question about users permissions in As documentation says |
A root user can change anything for anyone that a normal users can change for themselves.
That is untrue. |
Please do not comment on old issues. If you have a question, please use the forum. |
Hello, Gene
I have question regarding purpose of access control on
P2P
topic. So what is the purpose of it anyway?The reason why I ask this question is because I found that the purpose stated in documentation is somewhat contradict with the implementation written on code. So with this question I would like to validate what I found because I think it is very fundamental.
In documentation (see here) I found that the purpose of it is for managing presence + banning user from initiating or continuing
P2P
conversation. So if there areuser1
&user2
which haveP2P
connection, then after sometimeuser2
would like to block message fromuser1
, thenuser2
would be just only need to remove“W”
permission fromuser1
.But based on current implementation it is not possible to achieve that purpose. The reason is in current implementation it is not possible to change others permission on
P2P
topic, it is just for setting user own permission for filtering the data retrieved by user itself (which I personally think is somewhat useless on this context).So in above case,
user2
would only able to manage its own permission, so does withuser1
, so they cannot block each other in case they want to do it.So which purpose is true? Managing the
P2P
connection or just for filtering data retrieved from the context? Or maybe you have another design decision?Thanks a lot, Gene.
The text was updated successfully, but these errors were encountered: