feat: allow binding of arbitrary addresses

[MatthieuCoder]

Hello !

This pr adds support for specifying the addr argument in ListenAndServe, allowing the user to make the jwt service listen on a loopback address which is useful when using a reverse proxy / load balancer.

Some changes related to the lsp-auto-fmt behavior

[CLAassistant]

All committers have signed the CLA.

[ncs-pl]

Oh yes please, this would be really useful to me!

[Half-Shot]

Seems good, but would be good to keep backwards compat.

[fkwp]

Thx a lot for this contribution.

@MatthieuCoder sorry for the delay -- team is currently sprinting for MatrixConference :-)

339229b should address this issue - do you want to add a warning in the console akin to what's being done with LIVEKIT_LOCAL_HOMESERVERS ?

Yup a big fat warning sounds right. Besides that, it would be nice to also have a test around.

kind regards

[MatthieuCoder]

339229b should address this issue - do you want to add a warning in the console akin to what's being done with LIVEKIT_LOCAL_HOMESERVERS ?

Yup a big fat warning sounds right. Besides that, it would be nice to also have a test around.

This should now be implemented. Although a new variable eg. LIVEKIT_JWT_BIND_NETWORK_TYPE would be nice to allow listening on other network types such as unix just like synapse allows it.

With a default value of tcp it would allow transparent backwards-compatibility.

Regarding the tests, as this kind of "configuration" isn't tested currently, I did not implement it.

I already have a kind-of-working code but I would like some guidance regarding this contribution

[fkwp]

339229b should address this issue - do you want to add a warning in the console akin to what's being done with LIVEKIT_LOCAL_HOMESERVERS ?

Yup a big fat warning sounds right. Besides that, it would be nice to also have a test around.

This should now be implemented. Although a new variable eg. LIVEKIT_JWT_BIND_NETWORK_TYPE would be nice to allow listening on other network types such as unix just like synapse allows it.

With a default value of tcp it would allow transparent backwards-compatibility.

Regarding the tests, as this kind of "configuration" isn't tested currently, I did not implement it.

I already have a kind-of-working code but I would like some guidance regarding this contribution

On LIVEKIT_JWT_BIND_NETWORK_TYPE I suggest to make this a new follow-up PR.

On the testing you are right -- this would probably need a small refactoring to split out the config parsing. So for now, leave that with us.