-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
Extract create channel logic to separate function that doesn't require a logged in user #455
Comments
@rwakida , please take a look at REST apis bulk/register and buik/createRoom. Users with special 'roles' can call these methods. A 'role' example can possibly be an 'automated bot'. Accountability / audit-ability are important; creating a few million rooms in a short time will bring down the system. Is there any particular reason why you would want or need real anonymity when calling (essentially) super-user APIs? |
See #426 for more info on the bulk APIs. |
Thanks for the feedback @Sing-Li. I'm relatively new to RocketChat and Meteor so please bear with me 😄 With the current API, the "bot" would need to authenticate which would require an account right? If so:
I don't want or need anonymity, but it seemed more complex to introduce a way to flag a user as a "bot". To add to the confusion, I imagine that some "bots" should be able to direct message while others shouldn't. For audit-ability, I'd be happy with passing a name that gets logged, but not require a real user. |
Cool, @rwakida 😄
Once we refine roles and permissions - both 1 and 2 will be possible. Roles and permissions depend so much on specific deployment scenario. Maybe you can help us work on it. I still can't see non-logged in users/bots be able to do super-user actions except in lab installs - due to security/trust issues. Perhaps some ephemeral user, created by an existing admin (who will be responsible for its action). |
Thanks @Sing-Li. I understand your apprehension regarding non-logged in users. It sounds likes I'll have to wait for roles/permissions to be implemented. Is there a overview of what needs to be protected and where? Using alanning/meteor-roles? @engelgabriel supported extracting addUserToRoom logic so that non-logged in user can execute (#454), and suggested all methods should follow. If the team supports that decision, then it applies to this issue as well. So, I'm unsure if I should close this issue or not. |
Let me do the transition and I'll close it. |
Closing as this is possible to createChannels and privateGroups via the rest api and also the ddp connections. Setup a bot user, such as rocket.cat, in your rocket.chat and it will work. |
Use case:
Allows automated, anonymous channel creation on the server. For example, we create a channel based on a user's location, and automatically add the user to the channel.
The logic to validate name and create the room and subscriptions in the createChannel Meteor method would be extracted to a non-exposed serverside function that accepts name, members, and an optional creator. The createChannel Meteor method would check that the Meteor.userId() exists then delegate to the extracted method. The backend "bots" would call the extracted method and optionally pass a user as the room creator. We would also need #454 to be implemented
Questions:
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: