[vlc-devel] vlc, RTSP and digest authentication

[Ratin]

Rémi Denis-Courmont <rdenis <at> simphalempin.com> writes:
>    Hello,
> 
> On Mon, 10 Nov 2008 11:43:54 -0800, Ratin <ratin3 <at> gmail.com> wrote:
> > It seems that when a server signals vlc that the authentication is
> > required to get stream via RTSP by sending "401 UNAUTHORIZED",
> > vlc opens a new socket to resubmit its request.
> 
> With RTSP, sessions are NOT tied to transport connections.

before SETUP command gets processed, there is no RTSP session ID and thus a 
defined RTSP session, so I am a little confused as to what you referred 
as "sessions". I was under the impression that once the SETUP command gets
processed and the two party negotiates on RTP ports, etc, thats when an RTSP
session is born and any subsequnent control of the stream will be performed
on this session using the session id, the sockets can close etc. 
The problem I am chasing after happens during DESCRIBE, before SETUP..  

> > This poses a problem for the server because the server is supposed
> > to open a new client session for the new socket
> 
> No no. Go read RFC2326 (or draft rfc2326bis).
> RTSP sesions are not tied to sockets.

Again, the "RTSP session" hasn't born yet, we are just going thru creating
such session.  
My question is how do you identify the client when it closes the socket in the 
middle of a authentication session, by looking at its ip address? that wont be 
a valid check because one host can have multiple clients. 

> 
> > and the old authentication information such as the nonce etc
> 
> No. The authentication nonce cannot be tied to the transport connection.
> That would be silly since it's an extension to HTTP, and HTTP transport
> connection are stateless.

The digest authentication works per protection space (also called authentication
session) basis. If the socket is destroyed in the middle of authentication and 
a new socket is created by the client, the server will have to identify the 
client because it has to match the current response based on previously sent 
nonce. This brings up the state issue and RFC 2617 clearly talks about such 
state.

> 
> > Anybody experienced this issue?
> 
> I have not checked.
> 
> > I believe vlc is not complying with the RFC,
> 
> I believe your server is not complying with the RFC.
>