The server doesn't keep the RTSPSession around once an error was sent
back in the RTSP response. There is no need for it to keep the first
RTSPSession around when it gets the second RTSP request (this time with
the authentication headers).
Digest authentication works in DSS 4.0. Your qtaccess file is set up
incorrectly. The limit end tag is </Limit>, and not </Limit READ> or
</Limit WRITE>
What is really happening?
The access file authentication code finds a qtaccess file, but it is
incorrect, so the limit tags and all lines within them are ignored. The
qtaccess file is then a blank file. The presence of a qtaccess file
without any lines implies that no one is authorized to view the content
in this directory or broadcast to this directory.
Try changing your qtaccess file to :
<Limit WRITE>
require valid-user
</Limit>
require valid-user
Note: You don't need the <Limit READ> </Limit> directive for read
access, as the default is for read access. Anything outside the Limit
WRITE directives is treated as fields for read access.
Let me know if this doesn't work for you
mythili
On Wednesday, May 22, 2002, at 11:17 PM, Ross Finlayson wrote:
I'm having trouble getting Digest Authentication to work properly in
DSS 4.0 (while handling a RTSP "ANNOUNCE"). The problem seems to be
caused by the fact that DSS is creating a new "RTSPSession" object for
each incoming RTSP request.
My "qtaccess" file is set up as follows
<Limit WRITE>
require valid-user
</Limit WRITE>
<Limit READ>
require valid-user
</Limit READ>
and I have a password entry set up for the user "theuser" in the
"qtusers" file.
My client begins by sending an "ANNOUNCE" request without any
"Authorization:" header:
On debugging the DSS, I found that the problem seems to be that the
call to "GetSessionTask()" (in "TCPListenerSocket::ProcessEvent()")
causes a completely new "RTSPSession" object to be constructed for each
request. So, when handling the second "ANNOUNCE" request, the DSS is
using a different "RTSPSession" from the one that it used to handle the
first "ANNOUNCE" request. Because of this, the following code - in the
routine "RTSPSession::CheckAuthentication()", line 1440 - is not
working properly (when handling the second "ANNOUNCE"):
The first "if" is succeeding, as it should (because the "response"
digest in the request matches the hash that the server constructs).
However, because "fRTPSession" is completely new for this request,
"fRTPSession->GetAuthNonce()" is NULL, and so the second "if" also
succeeds. Because of this, this request gets marked as 'stale'.
Consequently, at the end of "RTSPSession::CheckAuthentication()",
"qtssUserName" is set to NULL, which later causes authentication to
fail.
My first thought was to try to fix this by changing the second "if" to:
if(fRTPSession->GetAuthNonce() != NULL
&& !(nonce->Equal(*(fRTPSession->GetAuthNonce()))))
.....
With this change, the second "ANNOUNCE" gets authenticated and succeeds
OK. However, the subsequent "SETUP" requests also fail with "401
Unauthorized", so it doesn't really help.
The real problem here is that "RTSPListenerSocket::GetSessionTask()" is
creating a new "RTSPSession" object for each request. If, instead, the
same "RTSPSession" object were used for both "ANNOUNCE" requests (and
the subsequent "SETUP"s), the Digest Authentication would probably work
correctly.
So, is this a bug? Has anyone gotten Digest Authentication to work
properly with DSS 4.0?
Ross.
_______________________________________________
streaming-server-developers mailing list | streaming-server-
email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/streaming-server-developers
Do not post admin requests to the list. They will be ignored.
