[Galene] Galene HTTP API error and various feedback

[Galene] Galene HTTP API error and various feedback

[Timothée Jaussoin]

Hi,

Thanks for the awesome work, I'm currently trying to wrap Galene into my 
project and I have an HTTP API error and a few feedback to provide as well:

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"
}

Feedback:

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

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.

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).

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) ?

Thanks again for this really nice project :)

Regards,

edhelas

[Galene] Re: Galene HTTP API error and various feedback

[Juliusz Chroboczek]

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

[Galene] Re: Galene HTTP API error and various feedback

[Timothée Jaussoin]

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

[Galene] Re: Galene HTTP API error and various feedback

[Dirk-Willem van Gulik]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

On 11 Jul 2026, at 15:04, Timothée Jaussoin <edhelas@movim.eu> wrote:
> Le 11/07/2026 à 12:50, Juliusz Chroboczek a écrit :
...
>>     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 :)).

I'd be a bit cautious when it comes to putting secrets in ENV variables (or passing them on the command line) -- as they can leak via an strategic `ps -aux, -elwf, etc) or via a well meaning Nagions, SNMP or other monitoring system.

Best to pass these by root-protected files, via socket/device or on a file descriptor -- e.g. see openssl or pgp/gpg for examples.

With kind regards,

Dw 


[-- Attachment #2: Type: text/html, Size: 1815 bytes --]

[Galene] Re: Galene HTTP API error and various feedback

[Timothée Jaussoin]

[-- Attachment #1: Type: text/plain, Size: 4803 bytes --]

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 togalene-leave@lists.galene.org

[-- Attachment #2: Type: text/html, Size: 8113 bytes --]