Add password parameter when creating new pad

[timtebeek]

Would it be possible to add a password parameter when creating a new pad? This way passwords can trivially be managed by users of an etherpad installation themselves, without needing an external management site using the API. The welcome page could then also be updated to add a password field to make it easy for users to use this functionality.
I'd envision this as a one time set operation, after which the user is left to distribute the password themselves, without any further password management.

[riseuplabs]

This would be a nice functionality!

[dora71]

I'd love to see that feature in a future release!

[JohnMcLear]

Either way you would need to use the API to do this so if I was you I would familiarize yourself with the API and create your own front end request to apply security.

[timtebeek]

The pad-creation hook in the new plugin API draft looks promising, but I'm guessing that's some time away..

I had hoped this would be possible without introducing a new dependency by using the HTTP API + whatever language, but I could see myself going that route eventually if need be.

[snaut]

important feature, for me this is the only feature that keeps me from switching to etherpad-lite.

[Pita]

This will be a plugin one day

[jhollinger]

+1. I believe that currently only group pads may have passwords? If this becomes a plugin someday, it implies that "normal" pads must be allowed to have passwords. Does it make sense to go ahead and remove that restriction from core? I can't think of any downside.

[timtebeek]

The plugins API seems to have come a long way since. Could this issue be retagged as a Plugin Request?

I'd also like to expand on @jhollinger 's last note: Would it be possible to allow "normal" (non-group) pads to have passwords? This restriction has meant one can not simply password protect a "normal" pad; one has to go all-in and manage Authors, Groups, Sessions & Pads before one is able to password protect a single pad. =\

[JohnMcLear]

Please create a vote for this plugin / feature on http://etherpad.idea.informer.com/

[JohnMcLear]

So here is how I see this working..
User hits up http://blah.com/p/jdflkjskldfjsdf?password=true

1. Because password=true we attempt to set a password
2. first we check for an existing password, if none exists we should a dialog to provide a password for this pad...
3. Future users that visit this pad are required to type in a password to access the pad contents..

We can do this a ghetto way just doing 99% of it on the client or we can attempt to create some sort of integration with the auth mechanism.. I'd suggest the latter which makes it a bigger job than just a bunch of hidden divs..

[JohnMcLear]

Help us help you: https://www.bountysource.com/issues/1371947-add-password-parameter-when-creating-new-pad

[xi]

I tried to work on this feature, but then I realized that there are serious limitations. But maybe I'm wrong:

• If anyone can set a password on a normal (non-group) pad, it is trivial to block other people from their own pads (DOS). So setting a password needs to be limited to pad creation.
• Pads are not listed anywhere, so they are protected by a "you need to know the URL" mechanism. I don't really see how "you need to know the password" is significantly more secure.

I still feel like this feature would make sense somehow. But before I seriously start working on it I would like to understand the thread model.

[dcht00]

* Pads are not listed anywhere, so they are protected by a "you need to know the URL" mechanism. I don't really see how "you need to know the password" is significantly more secure.

I thought so too, but started reconsidering this because of the HTTP "referer" situation (leaking your link to external sites by following URLs there!), also see #1603 and recently #3636 . Thought this is relevant to mention here.

[muxator]

@dcht00: Etherpad 1.8.0 will change its referrer policy and stop sending referer.

Discussion: #3636

[JohnMcLear]

Closing this as we're moving security outside of Etherpad.

[geor-g]

On 20-05-06 09:00:00, John McLear wrote: Closing this as we're moving security outside of Etherpad.

@JohnMcLear Mind to elaborate?

[JohnMcLear]

The concept that Etherpad should store/maintain etc. passwords is IMHO bad practice. Etherpad is not an authentication platform.

User management & Authentication platforms exist (think Auth0) and do a very specific job very well. 50% of Etherpad's technical debt is this horrible auth etc. so we're ripping it out so we can focus on the features users want.

This means plugins will provide different auth mechanisms (including password) and they can be responsible for password storage etc. See ep_hash_auth for example...