Hi,

Found it, in your documentation the PUT should have '{}' as a body, and not '' (empty string only).

Regards

Le 11/07/2026 à 15:04, Timothée Jaussoin a écrit :

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 !


_______________________________________________
Galene mailing list -- galene@lists.galene.org
To unsubscribe send an email to galene-leave@lists.galene.org