From: "Timothée Jaussoin" <edhelas@movim.eu>
To: Juliusz Chroboczek <jch@irif.fr>
Cc: galene@lists.galene.org
Subject: [Galene] Re: Galene HTTP API error and various feedback
Date: Sat, 11 Jul 2026 15:04:04 +0200 [thread overview]
Message-ID: <9342d9f8-42e6-4a9b-88d0-dc05ac7bd561@movim.eu> (raw)
In-Reply-To: <87se5ppzq0.wl-jch@irif.fr>
[-- Attachment #1: Type: text/plain, Size: 4315 bytes --]
Hi,
Thanks for the feedback, what about my curl EOF query issue in my
original message ?
curl -v -X PUT -u "admin:123" -H "Accept: */*" -H "If-None-Match:*"
-H "Content-Type:application/json"
http://localhost:8444/galene-api/v0/.groups/city-watch-4
Is returning:
2026/07/09 17:25:25 HTTP server error: EOF
Where
./galenectl create-group -group city-watch4
Works properly, with galenetctl.json config file being
{
"server": "http://localhost:8444",
"admin-username": "admin",
"admin-password": "123"
}
Do you know why ?
Added my answers to your feedback bellow :)
Le 11/07/2026 à 12:50, Juliusz Chroboczek a écrit :
> 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?
Having something like DotEnv (https://www.dotenv.org/docs/) to configure
Galene would even be better. Then you can launch it using a standard
file and environnement variable (which is really useful when you wrap it
in containers :)).
>
>> 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?
There :) https://github.com/jech/galene/issues/323
>
>> 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?
My primary goal would be to wrap Galene and offer a XMPP service
component for Movim (https://movim.eu), it's a bit similar than what
Goffi did but with some different approaches.
Each Galene group will be exposed as a XMPP user
(nightwatch@sfu.movim.eu) and XMPP users will be able to call it using
XMPP Jingle calls (https://xmpp.org/extensions/xep-0166.html) with Coin
(https://xmpp.org/extensions/xep-0298.html) to map the extra information
from Galene API and the SDPs (Coin basically add metadata to map
specific media-streams to a user if you call a SFU).
To do that I'd like to offer a really simple configuration to embed
Galene in Movim, so basically point to the binary and Movim wrap it
automagically (so creating a temporary admin to access the API and map
the Websockets to the XMPP Jingles "calls".
That's why I'd really like to have some kind of simplifications of the
configuration, a simple unique "wrapper" token that allows projects like
me to access the API and open websockets or something like that. For now
I'll try to "hack around" Galene to make it work but something more long
term would be awesome.
>
> -- Juliusz
Thanks ! Regards !
[-- Attachment #2: Type: text/html, Size: 6850 bytes --]
next prev parent reply other threads:[~2026-07-11 13:04 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 ` [Galene] " Juliusz Chroboczek
2026-07-11 13:04 ` Timothée Jaussoin [this message]
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=9342d9f8-42e6-4a9b-88d0-dc05ac7bd561@movim.eu \
--to=edhelas@movim.eu \
--cc=galene@lists.galene.org \
--cc=jch@irif.fr \
/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