introduce
Tailchat It is an open source noIM application that is plug-in and easy to expand. Scalable architecture gives unlimited possibilities. Tailchat
The front-end microkernel architecture + back-end microservice architecture enables the control of any customized/privatized scenario Tailchat
Created for enterprises and private domain users, highly free group management and customized panel display allow private domain owners to better display their works, manage users, and build their own brands and circles.
Official website: https://tailchat.msgbyte.com/
v1.9.0 update content
Feature updates
Add panel-level permission control management
A panel field has been added to the permission registration. When this field is set and matched to a certain panel type, the permission will be displayed in the advanced permission control.
Permission design is based on whitelist form. This means that he will inherit the group's permissions.
Example one:
- This role in the group has the [Send Message] permission
- This role does not have the [Send Message] permission in the panel
- Finally, this role has the [Send Message] permission in all text panels.
Example two:
- This role in the group does not have the [Send Message] permission
- This role has the [Send Message] permission in the panel
- In the end, the role only has the [Send Message] permission in the panels with permissions set above, and does not have the permission to send messages in other panels.
Q: Why does tailchat use the union of panel permissions and group permissions instead of permission override?
A: Because compared to many fixed-design applications, Tailchat needs to consider the design of plug-ins. Plug-ins can register customized permissions, and these permissions are uncontrolled. Only by allowing users to develop the habit of whitelisting permission management during their operations and actual use will the permissions not be out of control when new plug-ins are added. In addition, the behavior of overwriting is more unpredictable because it will overwrite each other.
An example is if we want users to have no permissions on a certain panel, but have permissions on other panels, then the most convenient way is to set the group scope to have permissions, but the panels not to have permissions. The lack of permissions on the panel will override the permission design of the group. But there is a difference here. We don’t know whether the user expects to have permissions by default or not by default. But currently he has permissions except for a certain panel. The difference between the two is that when a new panel is added, whether he expects to have permissions or not. permission denied. Tailchat wants to eliminate the mental coverage and understanding costs that the difference between the two situations brings to users, so it chose the most conservative way to design the permission system.
Other updates
- Fixed a possible xss attack because we allowed iframes to pass in srcdom, which could inject inline style code.