search

bluenviron / mediamtx

Ready-to-use SRT / WebRTC / RTSP / RTMP / LL-HLS media server and media proxy that allows to read, publish, proxy, record and playback video and audio streams.
MIT License
10.67k stars 1.39k forks source link

JWT authentication token too long for SRT publish #3430

Open dm-dma opened 3 weeks ago

dm-dma commented 3 weeks ago

Which version are you using?

v1.8.2

Which operating system are you using?

Describe the issue

In order to send the JWT token using SRT when JWT authentication is enabled, the JWT token is a part of the stream ID: srt://x.x.x.x:8890?streamid=publish:mystream:jwt=[token]

The issue with this implementation is that the streamid may only contain 512 characters. We created a token with almost the bare minimum but ended up with 685 characters: https://github.com/Haivision/srt/blob/master/docs/features/access-control.md

So technically this is not a bug and this is SRT related. But this leaves us with an implementation that is unusable, or is there another way to pass JWT tokens?

Describe how to replicate the issue

  1. start the server

  2. publish with ...

    
./srt-live-transmit udp://:5004 "srt://192.168.5.99:8890?streamid=publish:mystream:jwt=[token]" -v -s 100 -ll debug
Media path: 'udp://:5004' --> 'srt://192.168.5.99:8890?streamid=publish:mystream:jwt=[token]'
SRT parameters specified:

    streamid = 'publish:mystream:jwt=[token]'
Opening SRT target caller on 192.168.5.99:8890
16:52:24.463124/srt-live-transm D:SRT.sm: generateSocketID: : @310547703
WARNING: failed to set options: streamid,

ERROR #5003.0: Operation not supported: Bad parameters SrtCommon: DESTROYING CONNECTION, closing sockets (rt%310547703 ls%-1)... SrtCommon: ... done. ERROR: error: ConfigurePre: Operation not supported: Bad parameters



## Did you attach the server logs?

<!--
Server logs are sometimes useful to identify the issue.
If you think this is the case, set the parameter 'logLevel' to 'debug' and attach the server logs.
-->

no

## Did you attach a network dump?

<!--
If the bug arises when using MediaMTX with an external hardware or software, the most helpful content you can provide is a dump of the data exchanged between the server and the target (network dump), that can be generated in this way:
1) Download wireshark (https://www.wireshark.org/)
2) Start capturing on the interface used for exchanging packets (if the server and the external hardware or software are both installed on your pc, the interface is probably "loopback", otherwise it's the one of your network card)
3) Start the server and replicate the issue
4) Stop capturing, save the result in .pcap format
5) Attach
-->

no
aler9 commented 1 week ago

Hello, your analysis is right. Although the server tries to provide a protocol-independent set of features, sometimes it happens that a specific feature is not compatible with a certain protocol. JWTs are the standard way to authenticate requests without continuously polling an identity server, and supporting them has provided lots of benefits, but evidently they cannot be used with SRT. There isn't an easy solution for this.