Is there any way to restrict `update` propagation

[mk45]

In my setup I have read/write clients. Both may access document and its changes, but updates form 'read' clients should not be applied on document and propagated.

Is there a way to achieve this now? Or may it be a feature request 😉?

[mk45]

I m not sure maybe something like this:
mk45@02b5ef8
I will be grateful for Your opinion. I can make pull request later

[ivan-topp]

Hello, I find the functionality you are looking for interesting and the code you suggest as well. However, I have carried out tests implementing said suggestion and I have realized that it does not consider certain things, for your suggestion to work correctly I think that the implementation that you suggest should also be done for the client side both in socket events and in events through broadcast channel. Without considering this, there is a difference between the client and server document, since the server does what you want (not apply the update) but the client:

1. On the one hand, if you have the use of broadcast channel enabled, it transfers the change anyway (in case the same document is being used in more than one tab).

2. On the other hand, in case the broadcast channel is not being used (or it is being used but the update restriction implementation in the previous point has already been implemented) the client applies the change locally, but since the server rejects the update, the other clients connected to the document do not receive the change, which is perfect, the problem is that the client that made the rejected edition, since it already applied the change locally, is left with a state that differs from the state of the server, which results in in a false sense of editing to the user, which can be annoying to your user experience.

Currently as this package does not have a robust permissions system, the simplest thing for now is to "lock" the edit fields in the view so that the read-only user has no way to apply changes to the document (I know the latter is not is best, as it is always good for data security to have server-side validation). However, if you want to make an implementation that considers the points mentioned above, go ahead, I will gladly receive your contribution.

On the client side you could add a booleand that specifies if it is a read-only client and then in the provider validate that if it is a read-only client it does not apply the update locally or something similar and in this way I think you could achieve what you are looking for simple and complete way.

I hope I have been of help to you, I am attentive to your comments.

PS: It is planned that in version 2.0 of the package, this functionality will be considered along with others, but it would be for a medium/long term, due to the low availability that my work leaves me, for which I apologize.

[mk45]

Thank You for your reply and describing details about Your concerns.

I believe that credential information are obtained during some login proces so frontend have the knowledge about user restrictions and permissions. I planned to do as You said and make fields read-only on frontend but I must not thrust the frontend in my current setup.

The only part left is what You mentioned earlier: "It is always good for data security to have server-side validation". I guess I won't have enough time to make client part implementations, but I'll try to test proposed changes directly and fix its issues. I'll let You know if I have anything more to share or ask

[amirrezasalimi]

hi , i made a version with read,write permission handler in auth level , and when i tested in my project, will send pull request for this feature. @mk45
https://github.com/amirrezasalimi/y-socket.io
main...amirrezasalimi:y-socket.io:main

tnx for y-socket @ivan-topp

edit: there was a bug on checking , fixed