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

[Jan Janak]

On 17-04 16:52, Juha Heinanen wrote:
> Jan Janak writes:
> 
>  > The contents of the domain_attrs table is cased in domain module so there is
>  > no performance penalty.
> 
> sounds good to me.  if ser auth module is a superset (or can be made
> with little work) of k auth module then we should mv ser module to s-r
> common modules dir.

I think it should not be that hard. The biggest obstacle would be the format
of the subscriber/credentials table. We renamed table subscriber to
crendentials and changed its definition to:

  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.

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). Since you do not use UIDs in Kamailio, it can
simply be ignored.

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.

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
  * email_address -- We store all information about a particular user in
       attributes in the user_attrs table.
  * rpid -- The remote-party-id of the user is also stored in user_attrs
       in our case

  Jan.