[reSIProcate] RE: ServerAuthManager ?

[Daniel Pocock]

I've now put my patches and comments in JIRA:

http://track.sipfoundry.org/browse/RSP-30

It compiles and survived a few basic tests in both regular mode and 
Async mode.  Note that Async behaviour is not compulsory - it is still 
acceptable to return True or False values immediately (for instance, if 
a result is known from a local cache).



Scott Godin wrote:

>I mean - only send a 407 once - the 2nd time send a 404 or something
>else.  I'm envisioning a UA that always responds to a 407 with the same
>proxy auth headers (with mismatched realm).  I don't think a UA is
>likely to resubmit the request after a 404 response immediately (as
>opposed to a 407 response).
>
>  
>
>>-----Original Message-----
>>From: resiprocate-devel-bounces at list.sipfoundry.org
>>    
>>
>[mailto:resiprocate-
>  
>
>>devel-bounces at list.sipfoundry.org] On Behalf Of Dale R. Worley
>>Sent: Wednesday, February 22, 2006 5:27 PM
>>To: Resiprocate-devel
>>Subject: Re: [reSIProcate] RE: ServerAuthManager ?
>>
>>On Wed, 2006-02-22 at 13:58 -0500, Scott Godin wrote:
>>    
>>
>>>>I've started working on async, I've also reported a new issue that
>>>>        
>>>>
>I
>  
>
>>>>will fix as part of the async patch:
>>>>
>>>>    http://track.sipfoundry.org/browse/RSP-29
>>>>        
>>>>
>>>[Scott] We should be really careful about this.  We should only
>>>      
>>>
>issue a
>  
>
>>>407 if we haven't already done so for this request.  If we don't do
>>>      
>>>
>this
>  
>
>>>check we could get into an endless loop with poorly behaved UA's.
>>>      
>>>
>ie.
>  
>
>>>UA's that always just send a bad realm, when challenged.
>>>      
>>>
>>"As opposed to what?"
>>
>>We could send a 400 in response to a second identical attempt that has
>>the same authorization problem, but there's no guarantee that the UA
>>wouldn't attempt to re-send after that, either.
>>
>>If you mean, "Never send a 407 if it already has an authorization
>>header." that won't work -- a request can legitimately have several
>>authorization headers.  But maybe you have a way to detect whether a
>>request really is a re-send in response to a 407 from this proxy.
>>
>>Dale
>>
>>
>>_______________________________________________
>>resiprocate-devel mailing list
>>resiprocate-devel at list.sipfoundry.org
>>https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>>    
>>
>_______________________________________________
>resiprocate-devel mailing list
>resiprocate-devel at list.sipfoundry.org
>https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>  
>