* [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