Provide a per team site whitelist of domains for automatically approving new accounts

NEW
Unassigned

Status

Websites
Other
6 years ago
6 years ago

People

(Reporter: ozten, Unassigned)

Tracking

Details

(Reporter)

Description

6 years ago
Etherpad is very admin maintenance heavy.

Every team has a team site. A team site can have multiple pads.

An existing user on team site A cannot use a "team site B"'s pads. They must first be added by the admin of team site b.

We should add a new config feature which is a domain whitelist. If the user's email is hosted by one of these domains, they will automatically have an account created on team site B.

Configuration should be on a team site basis, not across the whole app.

Examples:
Someone creates a team site 'All'. This is suitable for anyone in Mozilla to edit and view. This pad is given some config for 'mozilla.com', 'mozilla.org', 'mozilla.co.uk', etc. Etherpad is restarted.

Infrasec wants to control their team site. They don't add a whitelist. Users still have to ask the 'Infrasec team site' admin to add them.
(Reporter)

Comment 1

6 years ago
I think per-site is too complicated. I would do this across the app.
Depends on: 701424
(Reporter)

Comment 2

6 years ago
Hi Jake. After a bunch of noodling, I think this will work best:

# List of email domains which are eligable for auto-account creation
account.autoCreate.email.hostnames = mozilla.com, mozilla.org, mozilla.co.uk,, mozillafoundation.org, mozilla-japan.org

# List of team pads which do not want auto account creation support
account.autoCreate.disable.teamPads = security, cabal

This config goes in etc/etherpad.local.properties and changes would require an etherpad restart.

This is a good balance between your time, user expectation, how many domains and subdomains will end up in the config file.

Let me know if this won't work or have feedback.

Comment 3

6 years ago
I'm mostly okay with this, I think... we should probably make an effort to ask pad owners beforehand whether they want this or not, though.

One concern that comes to mind is what happens on employee termination (or other loss of an account). BrowserID won't necessarily know the email address is no longer valid, will it? This would mean ex-employees could auto-add themselves to team sites, provided they've already validated that email address... right? I know this is a bit bigger problem in general.

I'm not particularly thrilled with the idea of auto-whitelisting whole domains. BrowserID is authentication... this change is authorization. It's not necessarily bad, but just makes me worried.

If we do this, I think we need to make sure the interface is very explicit about what domains are automatically approved, so that teams aren't surprised by the behavior. Otherwise this will appear to be "magic", and people (especially new people) will be constantly surprised by how and when it works or doesn't work. I would never have thought to add those other domains, for instance.
You need to log in before you can comment on or make changes to this bug.