[Live-devel] RTSPClient::describeURL authentication problems

[Ross Finlayson]

>  > Therefore, to solve your problem, would it be sufficient simply 
>to remove the
>>          authenticator == NULL &&
>>  from the "if" statement:
>>          if (authenticator == NULL
>>                  && parseRTSPURLUsernamePassword(url, username, password)) {
>>  so that it instead just says:
>>          if (parseRTSPURLUsernamePassword(url, username, password)) {
>>  ???
>>
>>  I.e., if the RTSP URL contains a "username:password@", then it would
>>  now supercede any (username,password) in the "authenticator".
>>
>>  Let me know if this would work for you?
>
>This alone would not work as then username and password from URL would
>override one from the authenticator.

Why would you not want this?

>  Another problem (addressed in the
>sent patch) is wrong error message about failure to handle response
>when in fact the code perfectly handles non-authorized situation via
>resubmitting the request later.

I don't understand what you mean by this.

>
>Plus there is the third issue: the library does not srip
>username:password@ prefix from the URL and sends them in clear text
>even with the digest authentication.

This is not our problem - nothing in the RTSP specification mentions 
modifying the supplied RTSP URL in any way, so we don't do it. 
People should not really be putting a "username:password@" in URLs 
anyway.

In any case, because VLC already has command-line option(s) for 
specifying the username and password, I wonder if perhaps the best 
solution would be to simply remove all support for handling 
"username:password@" in the "rtsp://" URL?  Not all servers support 
this anyway, and - as you noted, it's a security hole because the 
username and password are passed over the net in the clear.

Are there any servers out there than handle "username:password@", but 
which don't handle Digest Authentication instead?  Do we have any 
good reason for continuing to support "username:password@" at all??

>Here is more clarifications: the problem is that describeWithPassword
>resends the command on authentication failure while describeUrl does
>not.

That's not a 'problem' - that's just the way that the code works. 
The code can resubmit the command  (after an authentication failure) 
only if the user gave it a (username,password) to try.

This suggests that the real solution would be to change the VLC code 
to call "describeWithPassword()" rather than "describeURL()".  Or, 
even better, call "describeWithPassword()" iff the user supplied a 
(username,password), otherwise call "describeURL()".

Do you agree with this - i.e., that the best solution would be to 
change the way that VLC calls the LIVE555 libraries in this case??

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/