Extract create channel logic to separate function that doesn't require a logged in user

[rwakida]

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:

1. beforeCreateChannel hook passes the channel creator. Who would we pass? Looks like irc.server.coffee's IrcClient expects a user.
2. Is it okay to have a channel without a creator? The general channel doesn't have a creator.
3. Could have ghost rooms with no members.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Sing-Li]

@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?

[Sing-Li]

See #426 for more info on the bulk APIs.

[rwakida]

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:

1. Is there currently way to restrict a user from logging in with the "bot" account from the frontend, but still allow the "bot" to authenticate on the backend?
2. Is there currently a way to NOT return the "bot" as part of the list of users? e.g. A user should not be able to direct message a "bot" or add them to a group.

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.

[Sing-Li]

Cool, @rwakida 😄

1. not yet
2. not yet

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).

[rwakida]

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.

[engelgabriel]

Let me do the transition and I'll close it.