Skip to content
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

Allow anonymous use of the chat [$250] #604

Closed
mitar opened this issue Aug 28, 2015 · 69 comments · Fixed by #6797
Closed

Allow anonymous use of the chat [$250] #604

mitar opened this issue Aug 28, 2015 · 69 comments · Fixed by #6797

Comments

@mitar
Copy link
Contributor

mitar commented Aug 28, 2015

So currently, Rocket.Chat is a very much a Slack clone. But my main issue with Slack is that it is not open enough. So I would like an option to make Rocket.Chat more open. What I mean by that is that is that users can come and start reading what is happening on public channels without registration. So when a not-logged in user would open root address, they would get to the normal main screen, with all channels listed and so on. When they would open a channel, they could see what is happening there, but the message input box would be grayed out and a message to register/login to post would be there.

There is a $250 open bounty on this issue. Add to the bounty at Bountysource.

@mitar
Copy link
Contributor Author

mitar commented Aug 28, 2015

What does "Registration Required" set to false do? I have not seen any effect?

@frabrunelle
Copy link

👍

I am considering switching away from Slack and this is one of the main features I am looking for (being able to access and read the public channels without registration).

@AdrianoCahete
Copy link
Contributor

This needs to be an option for each channel. If the creator wants it, the channel can be read for unregistred users.

@mitar
Copy link
Contributor Author

mitar commented Sep 22, 2015

Or written to. I would really like that it can be like: user comes, sees channels (maybe flagged as such), and can read them, and can write an reply. And if the are not logged in, they have also to fill in the name in the status bar (which stays stored locally).

@mitar
Copy link
Contributor Author

mitar commented Sep 23, 2015

Bump:

What does "Registration Required" set to false do? I have not seen any effect?

@rwakida
Copy link
Contributor

rwakida commented Sep 23, 2015

@mitar Registration Required is not used at this time.

@mitar
Copy link
Contributor Author

mitar commented Sep 23, 2015

Heh, a setting which does nothing. ;-) OK, this is good, then it can be used for this particular purpose. So I would suggest that we make it so:

  • if "registration required" is false, then user can come and read all channels
  • if user wants to make a message, then another setting specifies if they have to register before doing that, or if they can just pick a name

I would say that concept of private and public channels should be for some other ticket/task.

@geekgonecrazy
Copy link
Contributor

for sure agree with @AdrianoCahete this needs to be maybe global to allow it. But needs to be a per channel setting.

@mitar
Copy link
Contributor Author

mitar commented Sep 23, 2015

But if I want to have all channels public, I do not want to enable per channel it every time.

I think that per channel permissions can be added later. Because those are two pretty different use cases still.

@mitar
Copy link
Contributor Author

mitar commented Sep 23, 2015

Maybe we could use a Meteor package which automatically creates an account for every user, and then just use permissions to do the rest. And allowing users to change the username and set password would then allow them to register the account once they decide to do so.

There are packages like:

Not sure which one is good.

@sampaiodiego
Copy link
Member

I've used meteor-accounts-guest for livechat package, and I don't think it's a good idea to create a user for every person who access rocket.chat. And if you setup this, you'll have no registration form, since every visitor will be automatically registered as a guest user.

I think you should just rely on admin settings to force user registration or not.

@geekgonecrazy
Copy link
Contributor

I agree. A user per guest is a bit too much over head just to let them see the channel.

@mitar
Copy link
Contributor Author

mitar commented Sep 23, 2015

And if you setup this, you'll have no registration form, since every visitor will be automatically registered as a guest user.

Yes, and then you have a registration-looking form which converts that guest user to a normal user. It sets username and password and e-mail, for example. It can look to the user the same as current registration form.

I agree. A user per guest is a bit too much over head just to let them see the channel.

I would like not just seeing the channels, but also posting. So posting without having to be registered (you just pick the name when you want to post).

@rodrigok
Copy link
Member

IMHO

  • We need an option to turn all or each channel public for read, no new users, just public as a web site
  • If user want to post something he should click in "Join Channel" and create an account to post.

@gmsecrieru
Copy link
Contributor

+1 to @rodrigok

@mitar
Copy link
Contributor Author

mitar commented Sep 23, 2015

Again, I think there are two features here and I think both should be supported:

  • anonymous reading
  • anonymous writing

I see that some people like the feature of anonymous reading, but I would also need anonymous writing.

@rodrigok
Copy link
Member

@mitar anonymous write is possible, but we can't provide consistency and is much hard to prevent flooding.

@ShaRose
Copy link

ShaRose commented Sep 25, 2015

For anonymous reading, you wouldn't need an account.
For anonymous writing, when you try to send your first message it should ask for you a temporary username (which would be bound to that IP address for, say, 24 hours after you last were in a channel), and also ask if you want to register an account.

Anonymous usernames might be pre or post pended with (Anon) or (Temp) or something as well, so users know they aren't registered (per server setting?).

Those sound like good ideas?

@joepie91
Copy link

+1

@geekgonecrazy
Copy link
Contributor

@ShaRose Might as well just use a normal session. Binding to an IP is generally a bad idea. Think public access. More then one user in a library / coffee shop? I've been in situations where I went to a sight and I was suddenly logged in as someone else ;)

@mitar
Copy link
Contributor Author

mitar commented Sep 26, 2015

Might as well just use a normal session.

+1

This is why I was proposing autocreation of accounts for each guest when you are in "no registration required" mode.

@rodrigok
Copy link
Member

Per room or general access options (radio - choose one):

  • No public (default)
    • READ: Only with an account
    • WRITE: Only with an account
  • Public read
    • READ: Public, anyone can read all messages
    • WRITE: Only with an account
  • Public read/write
    • READ: Public, anyone can read all messages
    • WRITE: Public, user will create an username (account without password and email) and this account can be used until user logout and keep using the same browser

Other options

  • We can require an email instead the username for public write, so we can send a generated password via email and the user can login back if necessary
  • We can generate a password and show to user in case he/she want to save the login data

@rodrigok rodrigok mentioned this issue Feb 14, 2017
2 tasks
@engelgabriel engelgabriel modified the milestones: 0.53.0, Mid-term Feb 14, 2017
@engelgabriel engelgabriel modified the milestones: 0.54.0, 0.53.0 Mar 3, 2017
@engelgabriel engelgabriel modified the milestones: 0.54.0, 0.55.0 Mar 22, 2017
@patcon
Copy link
Contributor

patcon commented Apr 3, 2017

fwiw, if this is critical to anyone, riot chat allows world-readable channels already: https://chat.tomesh.net/#/directory

@rasos
Copy link
Contributor

rasos commented Apr 23, 2018

Where can I define, which public channels are listed in the left column when arriving anonymously at the start page? Currently I see "undefined" only and directory does not allow to search (which is okay for users, but it should list public channels).

@lunitic
Copy link

lunitic commented Apr 23, 2018

@rasos Make the channel/rrom default and it will be showed there

@rasos
Copy link
Contributor

rasos commented Apr 23, 2018

@lunitic tnx, but where do I set a channel room to become default? Can't find it in any menu. We're on RC 0.62. I only can set it as favorite which is a per user setting.

@flantascience
Copy link

flantascience commented Apr 23, 2018 via email

@leonardorocc0
Copy link

Hi there
I don't see this is possible to make some channels available to anonymous users.
There is a public/private setting for each channel and the default flag but it doesn't mean I can exclude anonymous user from writing or seeing other public channels.
Do you think this could be added as a feature?
Thank you!

Shailesh351 pushed a commit to Shailesh351/Rocket.Chat that referenced this issue Apr 22, 2021
…0fbf9d

[Upstream Catchup] Merge RC:master to develop_pwa
@FynnMazurkiewicz
Copy link

Adding to what @leonardorocc0 is reporting: I have allowed anonymous write on my instance (3.14.0). I have disabled finding public channels via the directory or spotlight search for anonymous and guest roles. It seems the anonymous role is only assigned to users that register with a username via the "Sign in to talk anonymously" button. Now, an anonymous user without a nickname can find any public channel via the spotlight search and it is impossible to turn this off.

This mislead me to almost configure a security hole simply because I thought that if I disable finding public channels via spotlight on anonymous and guest, this will also cascade to the actual anonymous user without a username.

Is there any possibility to disable the spotlight results of public channels for anonymous users without a username?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.