Scott, I understand and I agree that there are two sides to the coin.
All I am suggesting is a method to allow a *default* username and
password to be set that is tried whenever a *specific* one for a
challenged realm can not be found .
Maybe calling AddCredential with an empty realm to set the default?
That way novices (or someone that wants it that way) can just set the
default and voila! it works.
IMHO It will expand the usefulness of the library.
M
"Opportunity is missed by most people because it is
dressed in overalls and looks like work."
Thomas Alva Edison - Inventor of 1093 patents,
including the light bulb, phonogram and motion pictures.
Scott Lawrence wrote:
On Wed, 2006-11-29 at 08:04 +0200, Marnus van Niekerk wrote:
Hi,
we came across a very similar problem in a project we are working on
and had to fix it by supplying two sets of credentials.
However, sipXtapi is the only UA I found that has this "strict"
mapping between realm and username/password.
In fact it was the only one that explicitly asks for a realm from the
user.
Every other UA I tried (linphone, kphone, xlite (windows and linux),
several hardphones and ata's) seem to have a "default" set of username
and password and uses it to respond to the realm presented by the
server. This way the UA does not need advance knowledge of the realm
which simplifies configuration.
But it doesn't work as well when you want multiple identities at
different SIP domains.
Would it not be a good idea to allow sipXtapi to set a "default"
username and password that will be used to respond to any realm for
which it does not explicitly have credentials. I have seen a couple
of messages where people struggle to get the auth working and I'm
convinced it is because of this difficulty as opposed to other UA's
they may have used before. There is also nothing in the RFC to
suggest the realm MUST match the domain from the URI or SRV lookups.
The RFC just says the realm MUST be globally unique.
Tx
M
PS: Also if you look at the RFCs, SIP digest auth was based on http
digest auth where the browser has no prior knowledge of the realm in
the challenge.
But the browser is free to use a cached set of credentials when
presented with a new challenge that uses the same realm, even if it's
from a different server. That was part of the point of requiring the
realm to be chosen so that it's unique.
|
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
