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 !