[FFmpeg-devel] RTSP over HTTP tunnel authentication

[Stas Oskin]

Hi.


> Do you have any sample URLs that we could test this with? When testing
> with DSS, the HTTP connection doesn't need any authentication at all,
> instead the tunneled RTSP communication does the auth negotiation just as
> usual.
>
>
I will send you the testing URL directly.
The DSS might be smart enough to link the auth info between GET and POST,
and allow non-auth POST, but in my case, the POST just receives
"un-authorized" message + 401 code which breaks the whole process.



> I do agree that something like this may be needed, but I'm unsure what the
> best way of handling it is.
>
> The problem is that authentication combined with (large) HTTP POSTs is
> tricky, to say the least. Normally, one would do the whole HTTP POST,
> sending both request header and body data, and only then you'd get the 403
> error reply saying which auth method to use (and a potential nonce, e.g.
> for digest auth). For this case, we would never get the 403 error telling
> us to reauthenticate until we're finished sending the POST data.
>
>
AFAIK the POST gets auth reject on first portion of data it sends.


> The proper solution to this is sending a Expect: 100-continue header in
> the POST request, then waiting for a while after sending the whole request
> header. The server is supposed to send either the 403 error, or an 100
> Continue reply, so that the auth can be negotiated before actually sending
> the body data of the request.
>
> The problem, of course, is that few servers actually implement Expect:
> 100-continue properly. Apache does, lighttpd doesn't. DSS doesn't
> implement it for the HTTP tunneling stuff either.
>
>
Again, in my experience, especially the Taiwanese equipment usually don't
contain any such logic and just goes on.


> Also, copying the whole auth_state struct like this probably isn't a good
> solution in general, since for digest auth, I'm not sure you're allowed
> to reuse the nonces from the other request. Instead you should do a new
> request, to get unique digest auth parameters for that connection. But
> that would require using Expect: 100-continue, which can't be relied upon.
>
>
This the exact behavior I seen with other RTSP implementations, notably
Live555. They typically re-use the auth header for POST as well. As in
FFMPEG it pretty tricky to get the priv_data->buffer outside, copying the
auth_state was the next best alternative as FFMPEG auth routines would
calculate exactly same header.

I agree though that a better implementation might be needed.


So for POST requests, I'm not sure if there's any good solution for
> general, multi-pass auth mechanisms. If we still want to support basic
> auth, we could perhaps do something like this:
>
>  if ( get_request_hd->auth_state->auth_type == HTTP_AUTH_BASIC)
>      post_request_hd->auth_state->auth_type  = HTTP_AUTH_BASIC;
>
> So if we know we should use basic auth, use that on the post session, too.
>

This approach might work too - thought from what I seen, the general notion
is to threat both GET and POST as single request, and share both the token
and auth info between them.

Regards.