Re: [reSIProcate] Digest credentials for many different usernames fromsingle realm
I'm not sure if 3 is really necessary - but I'm pretty sure that 4 is
required in order to function in situations where the realm returned is
not in anyway accurate (which I understand is quite common).
> Auth user is not exposed in 401/407 responses. Therefore I'm going to
> match user (which will be a new parameter of
> UserProfile::setDigetsCredential()) with user from the To header.
> (Note that matching with From does not solve my problem.)
I am concerned about this. Although it may solve your particular
problem, I don't think using the To: header is a good general solution,
and one that should be committed to SVN. In general you are providing
credentials about yourself, and the most appropriate spot to get that
info is the From header - definitely not the To header. Perhaps you
should be looking at overriding UserProfile with a customer version of
getDigestCredential for your purposes.
Scott
> -----Original Message-----
> From: Dmitry Semyonov [mailto:dsemyonov@xxxxxxx]
> Sent: Thursday, September 28, 2006 11:37 AM
> To: Scott Godin
> Cc: resiprocate-devel
> Subject: RE: [reSIProcate] Digest credentials for many different
> usernames fromsingle realm
>
> Hi Scott,
>
> On Thu, 28 Sep 2006 at 09:45 -0400, Scott Godin wrote:
>
> > I would like to see this change.
>
> OK, I think I'll be able to provide a patch tomorrow after some
> testing.
>
>
> > Although I vaguely remember starting
> > to do this myself a long while back and others had a reason that we
> > didn't really need it. Is anyone opposed to this?
> >
> > I think the search order should be:
> > 1. Find a credential where both user and realm match.
> > 2. If not found, return first credential with realm match.
> > 3. If not found, return first credential with user match.
> > 4. If not found, return first credential.
> >
> > I think it is fairly common for proxies to get the realm stuff
> > wrong, so we need some kind of fallback when the realm doesn't
> > match.
>
> Are #3 and #4 really necessary? This may indulge in writing erroneous
> code that nevertheless will _sometimes_ (depending on the order of
> credentials) work fine because DUM is excessively smart. (I realize
> that #4 is already implemented. But such DUM behavior already caused a
> bit of confusion to me.) Besides that #3 might complicate things to
> the level that does not worth the effort in my opinion.
>
> I even have doubts whether #2 makes sense. Although I'm going to save
> this behaviour for backward compatibility.
>
> Note however that my experience of working with authorizing SIP
> end-points is limited to SER proxy and Sipura ATAs. So I may be
> unaware of well-known interoperability issues with other products.
>
>
> > I guess you are planning to match Auth user with the user in the
> > From header?
>
> Auth user is not exposed in 401/407 responses. Therefore I'm going to
> match user (which will be a new parameter of
> UserProfile::setDigetsCredential()) with user from the To header.
> (Note that matching with From does not solve my problem.)
>
>
> > -----Original Message-----
> > From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > On Behalf Of Dmitry Semyonov
> > Sent: Wednesday, September 27, 2006 9:25 AM
> >
> > I propose to extend UserProfile interface to allow setting, getting
> > and clearing of credentials based not only on realm value but also
on
> > username (don't confuse with auth username!). It will be also
> > necessary to modify ClientAuthManager to retrieve credentials using
> > username from To header field of 401/407 response in addition to
> > realm value.
>
> --
> ...Bye..Dmitry.