Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: Juliusz Chroboczek <jch@irif.fr>
To: "Timothée Jaussoin" <edhelas@movim.eu>
Cc: galene@lists.galene.org
Subject: [Galene] Re: Galene HTTP API error and various feedback
Date: Sat, 11 Jul 2026 12:50:15 +0200	[thread overview]
Message-ID: <87se5ppzq0.wl-jch@irif.fr> (raw)
In-Reply-To: <a83f751c-57d9-42ac-9fd2-e048f68dcaf3@movim.eu>

Hello Thimothée, nice to meet you.

> 1. Its not written in the documentation that the API authentication is
> actually using Basic Auth, its a small thing but I had to dive in into
> galenectl code to understand that

Thanks, I'll fix that at the next opportunity.

> 2. I'd really like to be able to directly pass the admin-username and
> admin-password or directly an admin-api-key when launching ./galene, this
> will allow projects that wraps Galene like mine to not have to deal with
> galenectl and its custom file and generate a random username/password or
> api-key each time galene is launched.

That's something you could easily script:

    #!/bin/sh

    set -e
    umask 0077

    pw="$(dd if=/dev/random bs=8 count=1 | base64)"

    sed "s/@PASSWORD@/$pw/" < /etc/galene.conf.template > /tmp/galene.conf
    galene -c /tmp/galene.conf

So I'm not too keen to add code that I'm going to have to maintain forever
just to avoid a few lines of shell.  Is there any reason why you need this
to be done within the server itsef?

> 3. For projects that wrap Galene it would also be interesting if the API
> calls and open Websockets requests could be restricted to the local
> machine only (to prevent so security issues if the API is unfortunatelly
> exposed publicly).

That's a good idea.  Could you please file a github issue?

> 4. I'm not there yet but it seems that each "user" have to create
> a dedicated Websocket (see
> https://galene.org/galene-protocol.html#connecting) when wrapping Galene
> server side. This means that the wrapper will have to maintain dozens of
> Websockets. Would it be possible to provide a "admin" Websocket where all
> the messages are sent through it (with a specific user id to differenciate
> them) ?

It's a lot of work, and will require some protocol changes.  It is planned
to do that when (if?) I implement server federation.

Could you please describe exactly what you're doing, so I can think about
it some more?

-- Juliusz

  reply	other threads:[~2026-07-11 10:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09 15:43 [Galene] Galene HTTP API error and various feedback Timothée Jaussoin
2026-07-11 10:50 ` Juliusz Chroboczek [this message]
2026-07-11 13:04   ` [Galene] " Timothée Jaussoin
2026-07-11 13:07     ` Dirk-Willem van Gulik
2026-07-11 15:02     ` Timothée Jaussoin

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=87se5ppzq0.wl-jch@irif.fr \
    --to=jch@irif.fr \
    --cc=edhelas@movim.eu \
    --cc=galene@lists.galene.org \
    /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