* [Galene] Re: Thoughts on global user passwords [not found] <179043064484.1076.1779405941341360418@gauss> @ 2026-09-26 16:05 ` Juliusz Chroboczek 2026-09-27 14:18 ` Alexander Dietrich 0 siblings, 1 reply; 3+ messages in thread From: Juliusz Chroboczek @ 2026-09-26 16:05 UTC (permalink / raw) To: Alexander Dietrich; +Cc: Galene Mailing List > I've been experimenting with Galene recently, and really like it so far! Except > for the part where you potentially have to create the same "op" user accounts > in a bunch of groups, each with their own but identical password. (At least > that's my understanding of the current system.) Yes. The reason it's not a problem for me is that I generally create a whole hierarchy (using the "auto-subgroups" functionality) rather than a distinct group for every task. > I was wondering what you think about adding the ability to store > usernames/passwords for regular users in the "users" map of "data/config.json"? I've thought about it, but it's not that easy: - data/config.json is read-only, so it won't be possible to add new global users through the API; - you'd probably want users that only exist in a subhierarchy, for example a user that's an op in all groups under "group/teaching/*". So my take would be to create a database of users, similar to the token database. I encourage you to design and implement a proof of concept, but please be aware that it'll likely not be merged until we find satisfactory answers to the questions above (and others). -- Juliusz ^ permalink raw reply [flat|nested] 3+ messages in thread
* [Galene] Re: Thoughts on global user passwords 2026-09-26 16:05 ` [Galene] Re: Thoughts on global user passwords Juliusz Chroboczek @ 2026-09-27 14:18 ` Alexander Dietrich 2026-09-27 22:13 ` Juliusz Chroboczek 0 siblings, 1 reply; 3+ messages in thread From: Alexander Dietrich @ 2026-09-27 14:18 UTC (permalink / raw) To: Juliusz Chroboczek; +Cc: Galene Mailing List > - data/config.json is read-only, so it won't be possible to add new > global users through the API; Ok, using a separate file for this data would work as well. > - you'd probably want users that only exist in a subhierarchy, for > example a user that's an op in all groups under "group/teaching/*". My initial thought was to support global passwords only, and leave permissions in the group description. So the user would be "op" in "teaching", plus whatever is necessary for the subgroups? > So my take would be to create a database of users, similar to the token > database. > > I encourage you to design and implement a proof of concept, but please be > aware that it'll likely not be merged until we find satisfactory answers > to the questions above (and others). Ok, I'll start looking into it and see if I can come up with something sensible. Kind regards, Alexander ^ permalink raw reply [flat|nested] 3+ messages in thread
* [Galene] Re: Thoughts on global user passwords 2026-09-27 14:18 ` Alexander Dietrich @ 2026-09-27 22:13 ` Juliusz Chroboczek 0 siblings, 0 replies; 3+ messages in thread From: Juliusz Chroboczek @ 2026-09-27 22:13 UTC (permalink / raw) To: Alexander Dietrich; +Cc: Galene Mailing List > My initial thought was to support global passwords only, and leave > permissions in the group description. So the user would be "op" in > "teaching", plus whatever is necessary for the subgroups? The point is that we need something that's easy to explain and easy to export in the REST-like API. Early versions of Galene had a richer permissions model, but I found that it was impossible to map sensibly to a REST-like structure. -- Juliusz ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-09-27 22:14 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <179043064484.1076.1779405941341360418@gauss>
2026-09-26 16:05 ` [Galene] Re: Thoughts on global user passwords Juliusz Chroboczek
2026-09-27 14:18 ` Alexander Dietrich
2026-09-27 22:13 ` Juliusz Chroboczek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox