From: Juliusz Chroboczek <jch@irif.fr>
To: Jeroen van Veen <jvanveen@protonmail.com>
Cc: "galene@lists.galene.org" <galene@lists.galene.org>
Subject: [Galene] Re: User management
Date: Fri, 01 Oct 2021 13:55:46 +0200 [thread overview]
Message-ID: <87pmsp3qnx.wl-jch@irif.fr> (raw)
In-Reply-To: <9SCVvWIB9TfyEmG6di6LYCmoEeeJ_2Fsqzh8Y58_q0wSF1hRxJ_2I3YKATYXSCnaZQMJ6CdhvseVnbHsDmnSheS5b9SvRk1f9xhna0e2Y5Q=@protonmail.com>
> Any thoughts on a separate users.json that contains entries like:
>
> [
> {"name":"jeroen","password":"foobar","groups":{"pyrite":
> {"op":true,"presenter":true,"other":true}}},
> {"name":"pyrite","password":"foobar","groups":{}}
> ]
>
> The idea is to be able to set permissions per group, while having only
> one user entry at a central place.
I'm open to that.
> After modifying users.json, there will be another action from the
> backend that updates all accompanying group files. As I understand it,
> there is only 1 administrator user defined in data/passwd? Would it be
> feasible to have multiple users in there, so each user can have an
> administrator flag?
I think we should make the data/passwd file obsolete, and define the
administrator role per-user in the users.json file.
> And what would be a good approach to delete or rename a group? Doing
> a request to the new group name works fine to make it available in the
> list, but I wonder what will happen to the group that is being
> renamed/deleted.
The group will exist as long as there are users, but no new users should
be able to login. At least, that's the way the code was written, but
I don't recall if I've tested it.
> Should I use protocol.js in the backend as well to connect to a group
> and kick all users out, before attempting to rename/delete it?
I don't feel it's necesary, but it's up to you.
> If so, would it be useful to have a 'hidden' user available that can act
> on behalf of the backend?
No, please no hidden users -- normal users should have full visibility
into what's being done to them. If you need a system user, please make it
visible.
-- Juliusz
next prev parent reply other threads:[~2021-10-01 11:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-28 18:29 [Galene] " Jeroen van Veen
2021-10-01 11:55 ` Juliusz Chroboczek [this message]
2021-10-01 14:05 ` [Galene] " Dave Taht
2021-10-01 14:20 ` [Galene] End-to-end encryption [was: User management] Juliusz Chroboczek
2021-10-01 14:38 ` [Galene] Re: End-to-end encryption Michael Ströder
2021-10-01 15:24 ` [Galene] Re: End-to-end encryption [was: User management] Dave Taht
2021-10-03 19:15 ` [Galene] Re: User management Jeroen van Veen
2021-10-26 19:02 ` [Galene] Config branch [was: User management] Juliusz Chroboczek
2021-10-27 18:23 ` [Galene] " Jeroen van Veen
2021-10-29 9:10 ` Jeroen van Veen
2021-10-29 17:52 ` Juliusz Chroboczek
2021-10-30 8:22 ` Jeroen van Veen
2021-10-01 14:43 ` [Galene] Re: User management Dernat Rémy
2021-10-03 19:15 ` Jeroen van Veen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.galene.org/postorius/lists/galene.lists.galene.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pmsp3qnx.wl-jch@irif.fr \
--to=jch@irif.fr \
--cc=galene@lists.galene.org \
--cc=jvanveen@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox