Feature Request: Make it possible to set a password for guests

[miterion]

We currently use etherpad with a custom pad manager so we can set a password to view/edit a pad. This way the links can be shared and not be edited by anyone. Would it be possible to add this to hackmd?

[SISheogorath]

You can use the usual auth integrations + permission.

Set it to limited and only users that are able to authenticate to a pad, can edit or see it.

And sorry for the late response, we currently revisit all issues.

[SISheogorath]

Interesting idea:

You can set one password for a pad in the permission section and everyone who would find a 403 right now, like Guest when a note is marked as "Limited", "Protected" or "Private" or users in case of a "Private" one, will be prompted for the password. And additional checkbox, besides the password field should toggle write access to for these users.

It's a very basic feature, but should be enough.

[miterion]

This would be very cool, would love to see this implemented or implement it myself

[SISheogorath]

We would very welcome a PR ❤️. Can't say when I'll get into this.

Feel free to ask if you have questions 😄

Meet us in our Gitter-Space:

[SISheogorath]

From a UI perspective I did some experiments:

Note implementation

With label at the bottom:

---

Without at the bottom:

---

With label but over the deletion in between:

---

Without label but over the deletion in between:

---

403-page implementation

---

Right now, I didn't do any server-side implementation. So there is no branch for testing right now. I wonder what is preferred.

Any additional/alternative ideas?

[miterion]

I would add a submit button to the 403 page, since many people would expect this.

[ccoenen]

regarding the different variants: I believe "note password" alone is not enough, it needs the extra label. Especially when something is already entered and the hint inside the input is no longer visible.

Also, input and label needs some margins left and right.

[SISheogorath]

Is this better?

---

---

403 with button

---

For people who want to develop the backend part:
https://github.com/SISheogorath/hackmd/tree/feature/guestPassword

Also an interesting question: Should the password be visible or not? Includes the question: do we store the password for the note as a real secret (hashed password) or as plaintext password

[SISheogorath]

Hints for the backend implementation:

https://github.com/hackmdio/hackmd/blob/ca959012047bef3c0b2dd6f2974a8373a6615125/lib/response.js#L154-L158

https://github.com/hackmdio/hackmd/blob/ea9b1557f9834b2b140bd9b07488b5fca3953791/lib/realtime.js#L804-L811

https://github.com/hackmdio/hackmd/blob/ca959012047bef3c0b2dd6f2974a8373a6615125/lib/response.js#L20-L22

[miterion]

I have a few questions regarding the backend implementation:

• When the password gets send to the server (from the 403 page), it has to be checked somewhere. I would implement it as a noteAction (see below)
  https://github.com/hackmdio/hackmd/blob/ca959012047bef3c0b2dd6f2974a8373a6615125/lib/response.js#L366
  Would that be okay or is there a better place
• My first idea for saving the password during a session is to save it with a cookie. The key would be the node id, the value the password.

Would love some feedback on these questions

[SISheogorath]

It's actually a good question how to store or save the password during this time. I didn't really think about that right now.

In general, we should do this by passport as every other auth before.

https://github.com/antgraf/passport-localapikey <-- seems to be good and maintained

Our note password would be the API key in this case. Means, we need to implement the authentication strategy but not for the usual user accounts. This answers your question where to send the password. The usual /auth/<something> URL. I guess /auth/api would be fine.

I'm not sure if this works, but that's my idea for now.

[miterion]

I had an idea on how to make this without another authentication mechanism:

When a user sends the correct password for a note to the auth system the note id could be saved in the users session (when the password is correct). This way, the system only has to check whether the requested note id is in this session variable and grant/deny access to it.

Could this be done or are there problems with saving this into the session variable?

[SISheogorath]

Sounds fine, too. Can you provide some example code? I'm not completely sure how the implementation looks like, feel free to surprise me ^^

[SISheogorath]

If you can make it to land a PR until end of next week I'll review and merge it to 1.0.0-CE. Otherwise this Feature goes for next release

[miterion]

Please push it back to a later release, have a lot assignements at university right now

[SISheogorath]

@miterion hey, how is it going? Still interested in doing this?

[miterion]

@SISheogorath I do not think that I am able to work on this currently. If someone else wants to do it I would be really happy

[ccoenen]

I feel this is also related to #138, perhaps this is a way to have some notes encrypted?

[mgoldau]

Hi, are there any update on this feature, to protect certain pads by password? By the way, the current permissions, are mostly concerning edit permissions, only "private" states that only myself can view the pad. However the usecase for me is that I want to have a private pad, where only users with the password can view and edit, regardless if they authenticated/logged in or not. As I am using the service in a mass-installation (gwdg), I don't want to share some sensitive pads with the whole community.

[mz83ude]

Hi, are there any update on this feature, to protect certain pads by password? By the way, the current permissions, are mostly concerning edit permissions, only "private" states that only myself can view the pad. However the usecase for me is that I want to have a private pad, where only users with the password can view and edit, regardless if they authenticated/logged in or not. As I am using the service in a mass-installation (gwdg), I don't want to share some sensitive pads with the whole community.

Absolutely agree with the suggestion!

This is a necessary feature, especially in large installations (k-range).

[janit42]

+1

[alexpovel]

Also expressing interest in this.

[VaalaCat]

This feature is really necessary for me

[asakura42]

+1

[jmsjsph]

+1

[zubair1024]

+1