[Kamailio-Devel] [ openser-Bugs-2740437 ] PUBLISH authentication is wrong

[Iñaki Baz Castillo]

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>