From: "Timothée Jaussoin" <edhelas@movim.eu>
To: galene@lists.galene.org
Subject: [Galene] Re: Galene HTTP API error and various feedback
Date: Sat, 11 Jul 2026 17:02:25 +0200 [thread overview]
Message-ID: <849c5b3a-8661-4b90-8207-edc0616ceb94@movim.eu> (raw)
In-Reply-To: <9342d9f8-42e6-4a9b-88d0-dc05ac7bd561@movim.eu>
[-- 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 --]
prev parent reply other threads:[~2026-07-11 15:02 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
2026-07-11 13:07 ` Dirk-Willem van Gulik
2026-07-11 15:02 ` Timothée Jaussoin [this message]
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=849c5b3a-8661-4b90-8207-edc0616ceb94@movim.eu \
--to=edhelas@movim.eu \
--cc=galene@lists.galene.org \
/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