LiveKit Community

would be nice if the helm chart can set the api keys as secrets managed from an external secret manager in order to integrate those keys into our secrets deploy and rotation flows, here is our proposal: <https://github.com/livekit/livekit-helm/pull/64>

I’ll let <@U02EU2ZPTQU> and <@U03RM7G8Q6A> chime in here, but I do believe once the API is set (i.e. 1.0) we plan to offer Svelte, Vue and Web Components support.

hi <@U04EPM4Q2F6>,
yeah, Svelte support is planned once we released a stable react version.
Given that we’re basically already using the svelte store contract on the core layer in most places, we expect it to be an even thinner wrapper around core than the react version currently is.
When you say that `core` is exactly what your’re looking for, you’re thinking about wrapping it for Svelte yourself?

Hey <@U02EU2ZPTQU>, exactly! We find that core plays really well with Svelte stores, so we're considering of importing `@livekit/components-core` and building our own components, however understanding that there may be some breaking changes until the React components are stable and the official support for Svelte in components-js.

great to hear that you see it as a suitable underlying package!
the fact that we put up the warning about possible breaking changes rather prominently on the repo is to ensure people don’t have the wrong expectations. Assuming that you’re also a SvelteKit user, you’re probably pretty comfortable working with pre-release versions though :wink:
We’re expecting the components-react API to reach a stable status within the next one or two weeks.

If you’re willing to start experimenting a bit with wrapping core for Svelte before that already, the great advantage would be that in case you hit any unexpected roadblocks, I’m happy to discuss them with you and potentially get required changes in before releasing a 1.0 version of the core.

I would gladly share any feedback! Looking forward to 1.0 and first-class Svelte components :fire:

<@U032JMDR8TD> please thread your messages and do not tag someone specifically unless you’re already in a conversation with them. :pray::skin-tone-4:  

Erick wrote:
&gt; I'm using xcode 14.2, flutter 3.7, livekit 1.2

Hi dsa. Do you have an clues regarding this?

does this help? <https://stackoverflow.com/questions/74531499/flutter-user-defined-issue-xcode-unsupported-swift-architecture>

I'm going to downgrade the library and see if that helps

copying <@U02GAC58A79> to see if he has seen this before

It seems the issue is when adding this config inside `Podfile`:

```    target.build_configurations.each do |config|

      # Workaround for <https://github.com/flutter/flutter/issues/64502>
      config.build_settings['ONLY_ACTIVE_ARCH'] = 'YES' # &lt;= this line

    end```

I spent 2 days scrapping the apple dev forum, SO, reddit, and after I removed this config, I got some progress.

which Podfile is this? your app's Podfile?

hey <@U032JMDR8TD> Can you try refer to the settings in client-sdk-flutter/example <https://github.com/livekit/client-sdk-flutter/blob/main/example/ios/Podfile>?  This works on m1 mac with flutter 3.7.X for me.

<@U02GAC58A79> I had those lines before and got those results. I'll try it again. Thanks.

Sometimes strange failures are usually caused by caching. After confirming that there is no error with `flutter doctor -v`, you can try cd ios &amp;&amp; rm -rf Pods Podfile.lock, and run `flutter pub get` again,

signal_client_fail

Hey Li, it's difficult to know what is happening. Especially that the client is reconnecting.

Can you reproduce it? If so please include logs only for the user that's having issues (filtering out everyone else), and file an issue with specific repro steps.

also, please update to the latest.. 1.3.5 and 1.6.7.

yeah, you can definitely receive + decode video. But currently we don't have any examples showing the details.

The Go SDK will be able to receive the encoded bytes; but currently you'd have to manually detect the codec and then decode them.

You can also take a look at our <https://github.com/livekit/client-sdk-rust|Rust client SDK>, which will decode *and* display video in a native UI.

thanks, will take a look. Good to know that is possible :raised_hands:.

there is definitely a difference between not publishing vs muted.

Even when it's muted, WebRTC still needs to re-negotiate with every subscriber and each client (browser or native) need to spin up media decoders for every track it receives. It's much more efficient to not publish the track alltogether

Hey Mauro, a C# SDK isn’t planned at the moment.
Even if the Unity SDK will use C#, it will not be directly compatible

Hey Sree, definitely, you'd have to generate an access token (JWT) from your backend using one of our server SDKs. The process goes like:

1. Your frontend passes user's existing token (session/cookie/IAM Token)
2. your backend validates the it
3. your backend creates an access token with an unique identity for that user
4. your backend returns that token to your front end.
5. your frontend connects to LiveKit with that token

Hey <@U044VKEB1EC>, what would you consider an error condition in that case?

Actual errors should return an exception, which can be caught.

That particular check is to provide a consistent contract from our API, regardless of what the protobuf messages may contain.

For the getParticipants API, it's returning [] if there are no participants in that room.

Hmmm, in my case it was returning 0 even when there were participants in the room. It only happened very occasionally. I haven’t seen the issue for a few weeks, though. Will keep an eye out and see if I can capture any more info. 

For more context: I’m using this api to generate a participant count that doesn’t include “hidden” users (such as stream recorders, etc). So it is being called every time a participant joins or leaves to update the count. 

Ideally I’d be able to get this count without requesting the actual list of participants 

Are you looking for this count on the client side? or server side?

Server side. It is used for a queuing system for issuing access tokens. 

got it, we can look to return this in the Room object

filed here: <https://github.com/livekit/livekit/issues/1508>

the easiest way is to sign up for <http://livekit.io/cloud|livekit.io/cloud>. it has a generous free tier and in the dashboard you can generate tokens to try out flutter example apps

Here are my test commands:

Gstreamer Pipeline:
```gst-launch-1.0 rtpbin name=rtp autovideosrc ! \
video/x-raw,width=1280,height=720 ! \
x264enc ! rtph264pay ! \
rtp.send_rtp_sink_0 rtp.send_rtp_src_0 ! \
udpsink port=16106 host=0.0.0.0 sync=0 async=0 \
autoaudiosrc ! queue ! audioresample ! audioconvert ! \
opusenc ! rtpopuspay ! rtp.send_rtp_sink_1 rtp.send_rtp_src_1 ! \
udpsink port=16107 host=0.0.0.0 sync=0 async=0```
Join room command:
```livekit-cli join-room \
    --fps 30 \
    --room "room1" \
    --identity "camera1" \
    --publish <h264-udp://0.0.0.0:16106> \
    --publish <opus-udp://0.0.0.0:16107> \
    --api-key devkey \
    --api-secret secret```
Any advise will be greatly appreciated

Updating my gst command a bit but still facing the issue:

```gst-launch-1.0 autovideosrc \
    ! video/x-raw,framerate=30/1,width=1280,height=720 \
    ! x264enc \
    ! rtph264pay \
    ! queue max-size-bytes=0 max-size-buffers=0 \
    ! udpsink host=127.0.0.1 port=16106 sync=0 async=0 \
    autoaudiosrc \
    ! audioresample \
    ! audioconvert \
    ! opusenc \
    ! rtpopuspay \
    ! udpsink host=127.0.0.1 port=16107 sync=0 async=0```

```livekit-cli join-room \
    --fps 30 \
    --room "room1" \
    --identity "camera1" \
    --publish <h264-udp://127.0.0.1:16106> \
    --publish <opus-udp://127.0.0.1:16107> \
    --api-key devkey \
    --api-secret secret```
For testing streams:
```gst-launch-1.0 udpsrc \
caps='application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264'\
 port=16106 ! rtph264depay ! queue max-size-bytes=0 max-size-buffers=0 ! \
decodebin ! videoconvert ! autovideosink udpsrc \
caps='application/x-rtp,media=(string)audio,clock-rate=(int)48000,encoding-name=(string)OPUS'\
 port=16107 ! rtpopusdepay ! queue max-size-bytes=0 max-size-buffers=0 ! \
opusdec ! audioconvert ! audioresample ! autoaudiosink```

hey team, any assistance here would be appreciated

also, if there is anyone in the community that would be able to help here - we'd be open to some paid assistance

This thread can be disregarded, I figured out how to fix the TCP version

No, but you could use the rust SDK and link with C: <https://github.com/livekit/client-sdk-rust>

<@U01KZ61GV5Z> When will the Rust sdk support voice calls?

though my team let me know that the Rust SDK would not run for RTOS. It uses libwebrtc which doesn't compile for RTOS

<@U01KZ61GV5Z> In what way can I link to the Livekit server under the RTOS system

Thank you for the feedback &amp; bug reports <@U044VKEB1EC> !

CC: <@U03H6MNQ9G9>

p.s. I do love livekit very much! Such a versatile tool kit and platform :relaxed: 

I just tried a quick test using OBS and the default ingress settings. dumping the output using livekit egress track composite for analysis. In my case, the output was stereo, and I confirmed that it was indeed "real" stereo by playing with the balance setting in OBS. Could you confirm that OBS is set to output stereo, and give more details on your setup?

Thanks, I forgot to mention that this is running on the livekit cloud infrastructure and using server-sdk-js v1.0.1. I just realised that version is a little out of date, so I will try with latest and let you know. 

Obs is outputting stereo. I tried the same setup just with different stream keys to twitch, and it was stereo. 

I am bringing the rtmp stream into the sdk-client-js using Room and remote participant, but streaming the results out through web audio (same setup works in stereo for webrtc peers). 

But this is encouraging, it probably means there is something weird going on in setup, I will investigate further. 

What about the other issue with the name not coming through. Were you able to reproduce that?


The name seems to work too. I'm using the go SDK. I'll try the JS one when I get a chance

I just tried the latest version of js sdk and same problem. I will try with the cli just in case the issue is the js-sdk :)

The cli is what I used when I mentioned the GO SDK

I just tried setting up the ingress with CLI and it still not working in stereo.

I also simplified my test case to just be client-sdk-js connecting to room and then `track.attach(audioElement)`

Just checking if you tried the mono/stereo issue in FireFox? We can reproduce a similar issue in Chrome where it seems to downmix the stereo to mono.

Yes this was in chrome. But it is only down mixing the rtmp sources, everything else is fine. 

I seem to recall that they didn’t used to work in stereo either, but a few months back the right sdp magic was implemented and now they work. Maybe the rtmp system is missing this fix?

And yes, can confirm that stereo RTMP is working in firefox 

Here is a thread where this was discussed: <https://github.com/livekit/livekit/issues/970>

Also can confirm that applying the same sdp hack I used last time fixed this issue too (munging the incoming sdp with stereo=1). In that case, I have a temporary solution. Thanks for your help!

Yeah, we have a fix that involves making sure we set the stereo flag properly on the track

<@U03H6MNQ9G9> is there an update on stereo audio in the JS client for rtmp ingress? From my tests today, it still seems to be in mono. And my old hack doesn't seem to be fixing it anymore :confused:

Oh, managed to get my hack working again. Just needed to update my monkey patch for some internal api changes :slightly_smiling_face: so no rush on this

Thanks for the reminder. This (still unfinished) PR should hopefully fix it by notifying the SDK on the receiver to enable the workaround, through the livekit protocol: <https://github.com/livekit/ingress/pull/130/files>

There is an error where not equal is not performed on the id field, is there another way ?

I want to excluded items with some specific ids

I am just having a standalone VM machine. I see some inputs in this channel with docker run commands. But, unfortunately, my organization blocks docker. Hence, I followed this link to install, <https://docs.livekit.io/getting-started/server-setup/> on my linux.

Hence, please suggest me on how can I let LiveKit Server start as WSS instead of WS by using the SSL certs passed,

Hey Sree, you'd need to set up a reverse proxy that could terminate SSL. This could be done with Nginx or Caddy.

Hi,
Can embedded devices achieve real-time voice communication with livekit services? The embedded device runs on an RTOS system and can only be programmed using the C language.

If the embedded device running C language cannot communicate directly with Livekit, can we push the audio stream from the embedded device to an intermediate server and then use Livekit's Go SDK to forward it to Livekit?

Sharing here as well <https://livekit-users.slack.com/archives/C025KM0S1CK/p1678733148367259>

We’re getting closer <@U04R6CSFPD4>! We still have audio publish/subscribe to implement. This is being actively worked on right now.

you can give the connection test a try <https://livekit.io/connection-test>

Also, a request. Please post only in one channel (preferably in <#C01KVTJH6BX|>). We do monitor all channels. Helps us manage support stuff better :pray:

IMG_3840.jpg

<@U04U7JLV02D> for future posts, only a single channel (and ideally <#C01KVTJH6BX|> for support issues) please! Now that there’s already a thread going here, we can leave this one here.

do you mean within the SFU? it currently does not decode the packets so it wouldn't be able to know sample rate. Typically it'd be 48000.

There is a field for stereo in `TrackInfo`, so that should tell you if track is published as stereo or not

Hi, I don't think that's achievable unless you connect with another token / user. The reason why its disconnecting Window 1, only 1 identity can be used in the same room. (Which comes from the token creation)

You could probably create a seperate page for that *popup* window.. which could only show 1 participant.

Thanks for your answer, that's what I figured is happening. Hoping somebody has a workaround for this, otherwise it kinda kills LiveKit for my project... :(

So upon clicking on your user.. you could pass some parameters &amp; make that participant hidden.

so.. clicking could be something as <http://domain.com/popup.html?id={participant.sid|domain.com/popup.html?id={participant.sid>] per say.

Although, I haven't tested this using electron, I think it would work.

But that popup would need a Room and thus a token, wouldn't it?

But that wouldn't really matter, would it?

Set that participant as hidden so in your main window it doesnt show as an additional participant

Hm... window (1) has MyUser and his token, creating MyUserRoom. I'm getting the participants of the room. Clicking on one, window (2) opens. It needs to use MyUserRoom to connect, no?

window 2 only needs a new token to join that same room.

But you could create a brand new connection to livekit for that popup if you wished.

View this as 2 separate apps running, per say. I think this could be a way to achieve what you want.

I don't quit understand, wouldn't the second LiveKit connection need a token? How would I connect to the participant?

I think I'm getting it -- slowly. Creating a new connection, but not joining that room in window (1) means I'm not getting kicked out there.

Now, how do I connect to a participant outside a room? Should the two of us create a new Room?

You could create a random identity for window 2.. so window1 is always active

I'm not exactly sure what is your end goal, My suggestion was based on what you wrote in your initial question.. list of participants which opens a new Window upon click.

My end goal is simple: have a new stream window open for every chat participant.

Okay, then this should be an option to get this working if you want a new app window.

Alright, I will have some investigating to do then. Thank you very much for your time and help, Pat. I appreciate it!

Maybe someone else with more experience with Electron will be able to share a different approach, but I was more than happy to share some feedback.

a user with a similar need had raised an issue for electron: <https://github.com/electron/electron/issues/11275>

Basically the workaround that is suggested is to create a local RTC connection in order to make the mediastream receivable in window2.
That way you would not need to connect to the LiveKit server multiple times, but it will require a fair amount of custom logic to implement, I guess

I don’t think there are any disadvantages, the protocols are compatible between different languages.please continue

i want to create an app for livestream, i was curious if PHP LiveKit Server would serve me right

Sorry, I got it wrong, you should use <https://github.com/livekit/livekit|livekit-server> (written in golang) as livestream server, and use <https://github.com/livekit/client-sdk-flutter|livekit flutter sdk> to create app, here is a third-party <https://github.com/agence104/livekit-server-sdk-php>, but it is only used to manage tokens, room access permissions, and other controls. The actual media stream needs to be forwarded/exchanged through <https://github.com/livekit/livekit|livekit-server>.

I think <@U032TUAL4KT> — the author and maintainer of the LK PHP server SDK is building something in the livestreaming space and using the Go server SDK, too. Did I get that right, Pat?

Hi guys, we're also using php for the application and livekit's go server for livestreaming.

Basically we've just connected the twirp api of livekit in the php application :+1:  

Correct <@U01KZ0SCDKL>.  For my specific project currently I'm not using the PHP Server SDK but JS &amp; Go SDKs, although it could've been totally possible with PHP. <@U04UKE03BBK>, I don't see any disadvantage or downside of using the PHP SDK. Also if you run into any issues with the PHP SDK, please report it and I'll try to fix it as quick as I can. Also, as <@U02GAC58A79> stated, this is only used to interact with the LK Server.

Hi <@U046CJ4SRGU>, this is a good reminder for me to get a roadmap set up on GH. 

E2EE is coming along well, I’ll let <@U02EU2ZPTQU> and <@U02GAC58A79> who have been leading this say more.

hi <@U046CJ4SRGU> are you interested in a specific platform or generally curious?
We have a couple of things that still need to be ironed out, but getting close!

<@U02EU2ZPTQU> Hey Lukas, That's exciting. Been following e2ee on livekit since about October last year. We are using React Native. That's our primary platform. Planning to use Livekit Cloud w/ e2ee until there is the option to run a hybrid cloud dashboard + local deployment as discussed <https://github.com/livekit/livekit/issues/1378|here>. Willing to wait because the pricing model + dev experience with Livekit is superior.

Last I heard about RN was from <@U02GAC58A79> 2 months ago, “react-native-webrtc is maintained by another open source community, we may contribute a patch to their community, or make a patch for react-native-webrtc fork. once we finish e2ee testing, it should be possible to make a FrameCryptor patch for RN”.

FYI, regarding whether to contribute or fork. The primary contributor @saghul (on github) published this blog <https://jitsi.org/blog/a-stepping-stone-towards-end-to-end-encryption-on-mobile/|"A stepping stone towards end-to-end encryption on mobile"> (regarding React Native), so it could be beneficial reaching out.

As <@U02EU2ZPTQU> mentioned, our e2ee is still doing some final modifications to make flutter and js work perfectly, but I believe we will make progress soon.
Regarding react-native-webrtc I can’t give you an exact answer, the easiest way is probably to try the patch e2ee in a fork. Let’s verify its availability.

If you’re interested, you can check out the aes-gcm patch we made at libwebrtc.
<https://github.com/webrtc-sdk/webrtc/pull/54/files>

It's pretty stable now. There are folks that are using it in production.

With the next release, we plan to bump it up to version 1.0. That's planned for the next week or so.

Thats great !!!! I was using a webview to solve some issues but I’ll give a try again, thanks gruys if you need any help with the components lib on RN I will be happy to help

Hi, LK team,
We used <https://github.com/jitsi/rnnoise-wasm> in the react project, the noise reduction get good result. But how do I use this RNNoise reduction wasm in the app that based on livekit React-native SDK? Can you give some suggestions?

Hello <@U04UT7RMFSM>, yes it is possible through a Server SDK. An example with the JS server SDK would be found here: <https://github.com/livekit/server-sdk-js/blob/main/src/EgressClient.ts#L446>

For Golang, it is also possible with this method: <https://github.com/livekit/server-sdk-go/blob/main/egressclient.go#L84>

Hey, this isn’t currently possible with the WebGL SDK.

But this is planned for our Native Unity SDK :slightly_smiling_face:

Ok thanks. Look forward to seeing the result :+1:

A _big bank_ had several findings during their PEN test with Livekit.  One was:
```Pen Test - Session identifier (JWT) is sent via GET parameters
Description
Regarding the JWT, it is used to authenticate communications performed over the websocket. However, it is shared in the GET parameters of the requests.
This means it could be stored unencrypted in server or proxy's logs as well as on the user's computer logs. Having access to a valid JWT may allow an attacker to impersonate the user, preventing them to use the server and potentially accessing the video feed. However, the limited life of the JWT (10 minutes) limits the timeframe for an attacker to perform any attacks. It would also require the attacker to have prior access to the user's computer, to the server or to perform a Man In The Middle attack.```
I can see this in the nginx log on the livekit server that I’m using:
```109.164.195.26 - - [21/Mar/2023:09:20:40 +0000] "GET /livekitserver/rtc?access_token=eyJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJBUElWZGZoSGNKZ2dXZDYiLCJleHAiOjE2NzkzOTAxNjcsInN1YiI6IjZMN0VobEdhUk1LZmpYb252bGdWOGciLCJqdGkiOiI2TDdFaGxHYVJNS2ZqWG9udmxnVjhnIiwidmlkZW8iOnsicm9vbUpvaW4iOnRydWUsInJvb20iOiI0YjZlMWE1OC1iNTIxLTRiMmUtYjhhZi03NTg4MTRlZDE5OTUiLCJjYW5QdWJsaXNoIjp0cnVlLCJjYW5TdWJzY3JpYmUiOnRydWV9fQ.pwbPemg2pYKDNtmOHeHLp3mV5lG_00GvG772qH4cHl4&amp;auto_subscribe=1&amp;sdk=js&amp;version=1.6.4&amp;protocol=8&amp;adaptive_stream=1 HTTP/1.1" 101 5764 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36" "-"```
I do agree that sending a JWT token in a `GET` request isn’t really a good practice.

<@U01KZ61GV5Z> what do you think? Do you agree that it makes sense for me to create a security issue on github?

That's an interesting report. This said, I feel you could lower your TTL to 30s-1min, to reduce the risk window, but it is still not fixing the core concern.

If your security requirements are strict, you could turn off logs on your web server &amp; reduce TTL as much as possible.

Core problem can be solved by allowing user to establish WebSocket connection and then send token in the payload of the first message, but that would introduce other security and implementation problems.
I have been faced with this dilemma on my projects, and still haven’t figured out better solution than the one LiveKit is currently using :shrug:

Is this relevant?

<https://faqs.ably.com/is-it-secure-to-send-the-access_token-as-part-of-the-websocket-url-query-params>

I would say that article is not relevant, as it is obviously trying to assure you that there are no security risks, but there are... Chances are that your query parameters will be logged somewhere on some web server/proxy. The risk is real and scary.
That being said, there is a good mitigation strategy for this risk - make sure your tokens have low TTL and make sure that you don't log them in your system. I would say that if you are aware of this issue and have mitigation in place, you are as secured as it gets ;)

I think that's a fair point. While I don't see an actual security risk, I agree that not having it in the query parameters is *more* secure because headers are less likely to be logged.

LiveKit already supports taking access token in the `Authorization` header <https://github.com/livekit/livekit/blob/master/pkg/service/auth.go#L49|here>. However, the JavaScript websocket library does not appear to allow us to set header parameters.

thanks for the feedback <@U01KZ61GV5Z> I agree it’s not super bad but a bad practice as all query parameters will be stored in the browser history / server logs etc.
Having the auth header supported by the livekit server is already a good first step. So now we would only have to figure out how to get the websocket lib to support auth headers.
We’re discussing the severity with the Bank and could also offer to contribute to get this fixed.

not sure if this is what you’re suggesting <@U046B0LNLD7>, but LiveKit is not using any special websocket library for JS, but rather platform standards. This means a patch to support auth headers would mean a patch in all major browser implementations.

I’m just brainstorming here, but one way that might potentially have some benefits over the current approach:
• send the token via POST (or GET with proper headers) to the server
• server issues (and returns) a one-time-use CSRF token as a response
• websocket url gets that CSRF token appended instead of the original token
• server maps CSRF token to initial POST auth request, and (only) if it matches
• connection establishes

&gt; not sure if this is what you’re suggesting <@U046B0LNLD7>, but LiveKit is not using any special websocket library for JS, but rather platform standards. This means a patch to support auth headers would mean a patch in all major browser implementations.
Okay, I wasn’t aware of that.
&gt; • send the token via POST (or GET with proper headers) to the server
&gt; • server issues (and returns) a one-time-use CSRF token as a response
&gt; • websocket url gets that CSRF token appended instead of the original token
&gt; • server maps CSRF token to initial POST auth request, and (only) if it matches
&gt; • connection establishes
Yes this sounds like a possible solution, anotherone would be
• send the token via POST (or GET with proper headers) to the server
• set a cookie from the server side
• when sending the request to establish the websocket connection the cookie will be sent.
• server maps the cookie to the initial request
Both are rather similar though

Unfortunately both of these approaches would need a server side change

I think the suggestion you had with cookies is pretty good. It shouldn't be too much effort to add to livekit-server &amp; adding it as an option to JS SDK. We'll essentially need something like this:
• Server to support `/rtc/cookie_auth` endpoint, where it takes in a POST and stores `Authorization: bearer &lt;token&gt;` as a cookie
• JS SDK to take a `RoomConnect` option: `useCookieAuth: true` . when passed in, it'll first post to cookie_auth endpoint prior to initiating the websocket request (and will omit token from request params)

FWIW, there’s some concern about cross site websocket hijacking when using cookies instead of the CSRF approach
<https://www.coletiv.com/blog/using-websockets-with-cookie-based-authentication/>
<https://christian-schneider.net/CrossSiteWebSocketHijacking.html>

That's a good call Lukas. we need to understand the security implications of this too.

Good point. If you have a reverse proxy serving both the website and livekit through the same origin you could use `SameSite=Strict` on the cookie solving the problem. (This would work for our big customers as they’re serving everything so a big WAF).
However this doesn’t solve a typical cloud setup yet where the livekit server is running on another domain as the website.

In order to add an additional layer of safety for those cases 2 things could be done
1. origin whitelisting: adding a configuration to livekit from which origins a websocket can be opened. (Not very flexible so likely not a good approach)
2. using a CSRF token like you described. But then we have the problem again, that this token will be stored in the logs
None of these approaches are really great

out of curiosity, what's the concern with the CSRF token showing up in logs?

I think it’s definitely not as critical as having the access token there. I think as long as the CSRF token is a random one time token it shouldn’t be a big issue

<@U046B0LNLD7> what if you shrank the amount of time on the JWT token? would that satisfy the security folks over there?

It feels to me that it's fairly low risk to have a token that would expire in 5 mins.

We already have the default set to 30sec, I think they bumped them to a minute to be sure they don’t expire which minimizes the risk. But still they will go through the logs and if you are an evil IT guy 30sec - 1min is enough to use them in a malicious way. - So that won’t solve the issue

hey <@U04DUL22NF5> — we haven’t tested this, but I don’t see any inherent harm. I’ll defer to <@U022KB72NFJ> who may be aware of any specific gotchas.

Hey Matt, there should be no conflict :slightly_smiling_face:

Fantastic, thank you <@U022KB72NFJ> and <@U01KZ0SCDKL>. One more question - Agora's Unity WebGL plugin routes traffic through port 443 as a fallback if its attempts to use other ports are blocked by a firewall (as I'm sure you're aware, port 443 is the standard "firewall friendly" port for secure traffic). Does LiveKit have similar functionality? This is actually rather important for us since a lot of our corporate clients have restrictive firewalls - all of our platform's traffic either uses port 443 by default or falls back to port 443 if other ports are blocked. This allows our platform to operate correctly even if behind a firewall. Is this possible with LiveKit also?

<@U04DUL22NF5> I believe we use 443 by default. cc <@U01KZ61GV5Z> <@U02BBTRGF98>

This might also be helpful:
<https://docs.livekit.io/cloud/firewall/>

yup, what you’re looking for is “TURN.” it comes automatically with LK Cloud, and is available with LK Server as well.

<https://docs.livekit.io/oss/deployment/#improving-connectivity-with-turn>

Awesome, thanks <@U01KZ0SCDKL> and <@U02BBTRGF98>! :slightly_smiling_face: