[Kamailio-Devel] [ openser-Bugs-2740437 ] PUBLISH authentication is wrong
Iñaki Baz Castillo
ibc at aliax.net
Fri Apr 17 16:28:19 CEST 2009
2009/4/17 Jan Janak <jan at iptel.org>:
> CREATE TABLE credentials (
> auth_username VARCHAR(64) NOT NULL,
> did VARCHAR(64) NOT NULL DEFAULT '_default',
> realm VARCHAR(64) NOT NULL,
> password VARCHAR(28) NOT NULL DEFAULT '',
> flags INT NOT NULL DEFAULT '0',
> ha1 VARCHAR(32) NOT NULL,
> ha1b VARCHAR(32) NOT NULL DEFAULT '',
> uid VARCHAR(64) NOT NULL,
> KEY cred_idx (auth_username, did),
> KEY uid (uid),
> KEY did_idx (did),
> KEY realm_idx (realm)
> );
>
> Column 'did' is rarely used and we can ignore it, it can simply be filled with
> the default value. Column 'uid' contains the uid of the user who is
> authenticating.
How looks auth_username? "alice", "alice at domainA.org" or
"sip:alice at domainA.org"?
How do you handle a multidomain environment? For example: how to fill
the above table with these two users?:
sip:alice at domainA.org
sip:bob at domainB.net
Also, Kamailio has an option to use domain or not (in various
modules), so domain is checked or not (this improves the DB access in
single-domain environments).
> This is the unique id of the user within the system. Authentication functions
> in SER store the value of the column in an AVP after successful authentication
> and this is the primary ID of the user we use in other functions (we no longer
> rely on comparing SIP URIs).
Could you show an example of usage of uid column? which value does it contain?
> Column flags contains various flags generic flags. This column is present in
> many other tables within our schema. This column is used to store meta-data
> about the row. For example, there is a flag that marks the row "disabled" and
> SER would then pretend that the row does not exist. We can disable a set of
> credentials this way without removing it from the database. Anothe flags can
> be used to mark the row as deleted, while the actual deletion is performed by
> a cron job. And so on. Here we would only need to make sure that the provision
> script sets the column to a meaningful default value, so that the
> authentication module can use the records, that's it.
This is great.
> The following columns from your subscriber table are missing:
> * id -- We could perhaps use the uid column instead.
> * domain -- We can use the did column instead of domain
How?
> * email_address -- We store all information about a particular user in
> attributes in the user_attrs table.
email_address was removed from subscriber table long time ago :)
--
Iñaki Baz Castillo
<ibc at aliax.net>
More information about the Devel
mailing list