Hi,
Found it, in your documentation the PUT should have '{}' as a body, and not '' (empty string only).
Regards
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 :
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 :)).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 thatThanks, 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?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.
-- JuliuszThanks ! Regards !
_______________________________________________ Galene mailing list -- galene@lists.galene.org To unsubscribe send an email to galene-leave@lists.galene.org