search

turms-im / turms

🕊️ The world's most advanced open source instant messaging engine for 100K~10M concurrent users https://turms-im.github.io/docs
Apache License 2.0
1.77k stars 277 forks source link

Support limitation of creating message based on the user role or other conditions #1289

Open guvalua opened 1 year ago

guvalua commented 1 year ago

What is the best implementation to support limitation of creating message based on the user role or other conditions, for example one based on the role(VIP or not), can only send a limited number of message to another?

Implement a plugin which check the limitation via HttpClient connected to the business server , or some other ways?

Any advices?NEED HELP.

JamesChenX commented 1 year ago

You can implement your own quote in 3 ways at least:

  1. Implement your own plugin. turms-service has an extension point im.turms.service.infra.plugin.extension.ClientRequestHandler, you can get the requester ID and the recipient ID or group ID if it's a CreateMessageRequest from its input param ClientRequest clientRequest, and you can try to implement your own quota limiting plugin based on it. I think this may be the best solution for your use cases.

  2. Maintain your own repo. If your use cases are complex, you can modify Turms source code for your use cases. Every Turms User has a property permissionGroupId, which is just like the role you mentioned, and every role has its own quota limiting stored in im.turms.service.domain.user.po.UserPermissionGroup. And you may implement your business logic based on it, but it's not recommended because if you modify the source code of Turms, you need to maintain your code and distribution yourself.

  3. Wait for us to implement the solution ②. We may support message quota-limiting features in the future, and the solution will be similar to the solution ② as mentioned above. But we can just implement common use cases so that most users can benefit from it, you can not use it directly if your use cases are complex. And I am busy recently, so no effort for the solution currently. So you better not wait for me.