2
0
Эх сурвалжийг харах

modules/auth_db: regenerate README

Klaus Darilion 12 жил өмнө
parent
commit
76709d2ea2
1 өөрчлөгдсөн 142 нэмэгдсэн , 139 устгасан
  1. 142 139
      modules/auth_db/README

+ 142 - 139
modules/auth_db/README

@@ -1,4 +1,3 @@
-
 Auth_db Module
 
 Jan Janak
@@ -25,10 +24,10 @@ Jan Janak
 
    <[email protected]>
 
-   Copyright © 2002, 2003 FhG FOKUS
+   Copyright © 2002, 2003 FhG FOKUS
 
-   Copyright © 2005 Voice Sistem SRL
-     _________________________________________________________________
+   Copyright © 2005 Voice Sistem SRL
+     __________________________________________________________________
 
    Table of Contents
 
@@ -54,12 +53,12 @@ Jan Janak
 
         4. Functions
 
-              4.1. www_authenticate(realm, table [, method]) 
-              4.2. www_authorize(realm, table) 
-              4.3. proxy_authenticate(realm, table) 
-              4.4. proxy_authorize(realm, table) 
-              4.5. auth_check(realm, table, flags) 
-              4.6. is_subscriber(uri, dbtable, flags) 
+              4.1. www_authenticate(realm, table [, method])
+              4.2. www_authorize(realm, table)
+              4.3. proxy_authenticate(realm, table)
+              4.4. proxy_authorize(realm, table)
+              4.5. auth_check(realm, table, flags)
+              4.6. is_subscriber(uri, dbtable, flags)
 
    List of Examples
 
@@ -101,19 +100,19 @@ Chapter 1. Admin Guide
 
    4. Functions
 
-        4.1. www_authenticate(realm, table [, method]) 
-        4.2. www_authorize(realm, table) 
-        4.3. proxy_authenticate(realm, table) 
-        4.4. proxy_authorize(realm, table) 
-        4.5. auth_check(realm, table, flags) 
-        4.6. is_subscriber(uri, dbtable, flags) 
+        4.1. www_authenticate(realm, table [, method])
+        4.2. www_authorize(realm, table)
+        4.3. proxy_authenticate(realm, table)
+        4.4. proxy_authorize(realm, table)
+        4.5. auth_check(realm, table, flags)
+        4.6. is_subscriber(uri, dbtable, flags)
 
 1. Overview
 
-   This  module  contains  all authentication related functions that need
-   the  access  to the database. This module should be used together with
-   auth module, it cannot be used independently because it depends on the
-   module.  Select  this  module  if  you  want  to use database to store
+   This module contains all authentication related functions that need the
+   access to the database. This module should be used together with auth
+   module, it cannot be used independently because it depends on the
+   module. Select this module if you want to use database to store
    authentication information like subscriber usernames and passwords. If
    you want to use radius authentication, then use auth_radius instead.
 
@@ -124,15 +123,14 @@ Chapter 1. Admin Guide
 
 2.1. Kamailio Modules
 
-   The  module  depends  on the following modules (in the other words the
+   The module depends on the following modules (in the other words the
    listed modules must be loaded before this module):
      * auth -- Generic authentication functions
-     * database  --  Any  database  module  (currently  mysql,  postgres,
-       dbtext)
+     * database -- Any database module (currently mysql, postgres, dbtext)
 
 2.2. External Libraries or Applications
 
-   The  following  libraries  or  applications  must  be installed before
+   The following libraries or applications must be installed before
    running Kamailio with this module loaded:
      * none
 
@@ -151,13 +149,12 @@ Chapter 1. Admin Guide
 3.1. db_url (string)
 
    This is URL of the database to be used. Value of the parameter depends
-   on  the  database  module  used.  For  example  for mysql and postgres
-   modules this is something like
-   mysql://username:password@host:port/database. For dbtext module (which
-   stores  data in plaintext files) it is directory in which the database
-   resides.
+   on the database module used. For example for mysql and postgres modules
+   this is something like mysql://username:password@host:port/database.
+   For dbtext module (which stores data in plaintext files) it is
+   directory in which the database resides.
 
-   Default value is "mysql://kamailioro:kamailioro@localhost/kamailio". 
+   Default value is “mysql://kamailioro:kamailioro@localhost/kamailio�.
 
    Example 1.1. db_url parameter usage
 ...
@@ -166,11 +163,10 @@ modparam("auth_db", "db_url", "dbdriver://username:password@dbhost/dbname")
 
 3.2. user_column (string)
 
-   This  is  the  name  of the column holding usernames. Default value is
-   fine  for  most people. Use the parameter if you really need to change
-   it.
+   This is the name of the column holding usernames. Default value is fine
+   for most people. Use the parameter if you really need to change it.
 
-   Default value is "username".
+   Default value is “username�.
 
    Example 1.2. user_column parameter usage
 ...
@@ -180,10 +176,10 @@ modparam("auth_db", "user_column", "user")
 3.3. domain_column (string)
 
    This is the name of the column holding domains of users. Default value
-   is  fine  for  most  people.  Use  the parameter if you really need to
-   change it.
+   is fine for most people. Use the parameter if you really need to change
+   it.
 
-   Default value is "domain".
+   Default value is “domain�.
 
    Example 1.3. domain_column parameter usage
 ...
@@ -192,13 +188,13 @@ modparam("auth_db", "domain_column", "domain")
 
 3.4. password_column (string)
 
-   This  is  the  name  of the column holding passwords. Passwords can be
+   This is the name of the column holding passwords. Passwords can be
    either stored as plain text or pre-calculated HA1 strings. HA1 strings
-   are  MD5 hashes of username, password, and realm. HA1 strings are more
-   safe  because  the server doesn't need to know plaintext passwords and
+   are MD5 hashes of username, password, and realm. HA1 strings are more
+   safe because the server doesn't need to know plaintext passwords and
    they cannot be obtained from HA1 strings.
 
-   Default value is "ha1".
+   Default value is “ha1�.
 
    Example 1.4. password_column parameter usage
 ...
@@ -207,9 +203,9 @@ modparam("auth_db", "password_column", "password")
 
 3.5. password_column_2 (string)
 
-   As  described  in the previous section this parameter contains name of
-   column   holding   pre-calculated  HA1  string  that  were  calculated
-   including the domain in the username. This parameter is used only when
+   As described in the previous section this parameter contains name of
+   column holding pre-calculated HA1 string that were calculated including
+   the domain in the username. This parameter is used only when
    calculate_ha1 is set to 0 and user agent send a credentials containing
    the domain in the username.
 
@@ -226,23 +222,23 @@ modparam("auth_db", "password_column_2", "ha1_2")
    HA1 string or plaintext passwords for authentification.
 
    If the parameter is set to 0 and the username parameter of credentials
-   contains  also  "@domain"  (some  user agents append the domain to the
-   username  parameter), then the server will use the HA1 values from the
-   column specified in the "password_column_2" parameter. If the username
+   contains also “@domain� (some user agents append the domain to the
+   username parameter), then the server will use the HA1 values from the
+   column specified in the “password_column_2� parameter. If the username
    parameter doesn't contain a domain, the server will use the HA1 values
-   from the column given in the "password_column"parameter.
+   from the column given in the “password_column�parameter.
 
-   If  the  parameter  is  set to 1 then the HA1 value will be calculated
-   from the column specified in the "password_column" parameter.
+   If the parameter is set to 1 then the HA1 value will be calculated from
+   the column specified in the “password_column� parameter.
 
-   The "password_column_2"column contain also HA1 strings but they should
-   be  calculated  including  the  domain  in  the username parameter (as
-   opposed  to password_column which (when containing HA1 strings) should
+   The “password_column_2�column contain also HA1 strings but they should
+   be calculated including the domain in the username parameter (as
+   opposed to password_column which (when containing HA1 strings) should
    always contains HA1 strings calculated without domain in username.
 
-   This  ensures  that  the  authentication  will  always work when using
-   pre-calculated  HA1  strings,  not  depending  on  the presence of the
-   domain in username.
+   This ensures that the authentication will always work when using
+   pre-calculated HA1 strings, not depending on the presence of the domain
+   in username.
 
    Default value of this parameter is 0.
 
@@ -253,15 +249,15 @@ modparam("auth_db", "calculate_ha1", 1)
 
 3.7. use_domain (integer)
 
-   If  true  (not  0),  domain  will  be also used when looking up in the
-   subscriber  table.  If  you  have a multi-domain setup, it is strongly
-   recommended  to  turn  on this parameter to avoid username overlapping
+   If true (not 0), domain will be also used when looking up in the
+   subscriber table. If you have a multi-domain setup, it is strongly
+   recommended to turn on this parameter to avoid username overlapping
    between domains.
 
-   IMPORTANT:  before  turning on this parameter, be sure that the domain
+   IMPORTANT: before turning on this parameter, be sure that the domain
    column in subscriber table is properly populated.
 
-   Default value is "0 (false)".
+   Default value is “0 (false)�.
 
    Example 1.7. use_domain parameter usage
 ...
@@ -272,15 +268,15 @@ modparam("auth_db", "use_domain", 1)
 
    This parameter specifies of credentials to be fetch from database when
    the authentication is performed. The loaded credentials will be stored
-   in  AVPs.  If the AVP name is not specificaly given, it will be used a
+   in AVPs. If the AVP name is not specificaly given, it will be used a
    NAME AVP with the same name as the column name.
 
    Parameter syntax:
-     * load_credentials = credential (';' credential)* 
-     * credential = (avp_specification '=' column_name) | (column_name) 
-     * avp_specification = '$avp(' + 'i:'ID | 's:'NAME | alias + ')' 
+     * load_credentials = credential (';' credential)*
+     * credential = (avp_specification '=' column_name) | (column_name)
+     * avp_specification = '$avp(' + 'i:'ID | 's:'NAME | alias + ')'
 
-   Default value of this parameter is "rpid".
+   Default value of this parameter is “rpid�.
 
    Example 1.8. load_credentials parameter usage
 ...
@@ -291,10 +287,10 @@ modparam("auth_db", "load_credentials", "$avp(i:123)=rpid;email_address")
 
 3.9. version_table (integer)
 
-   If  set to 0, the module will skip checking the version for subscriber
+   If set to 0, the module will skip checking the version for subscriber
    table.
 
-   Default value is "1 (check for table version)".
+   Default value is “1 (check for table version)�.
 
    Example 1.9. version_table parameter usage
 ...
@@ -303,45 +299,51 @@ modparam("auth_db", "version_table", 0)
 
 4. Functions
 
-   4.1. www_authenticate(realm, table [, method]) 
-   4.2. www_authorize(realm, table) 
-   4.3. proxy_authenticate(realm, table) 
-   4.4. proxy_authorize(realm, table) 
-   4.5. auth_check(realm, table, flags) 
-   4.6. is_subscriber(uri, dbtable, flags) 
+   4.1. www_authenticate(realm, table [, method])
+   4.2. www_authorize(realm, table)
+   4.3. proxy_authenticate(realm, table)
+   4.4. proxy_authorize(realm, table)
+   4.5. auth_check(realm, table, flags)
+   4.6. is_subscriber(uri, dbtable, flags)
 
 4.1.  www_authenticate(realm, table [, method])
 
    Name alias: www_authorize(realm, table)
 
-   The  function  verifies  credentials  according  to  RFC2617.  If  the
-   credentials  are  verified successfully then the function will succeed
-   and  mark  the  credentials  as  authorized (marked credentials can be
-   later  used  by  some  other functions). If the function was unable to
-   verify  the  credentials  for  some  reason  then it will fail and the
-   script should call www_challenge which will challenge the user again.
+   The function verifies credentials according to RFC2617. If the
+   credentials are verified successfully then the function will succeed
+   and mark the credentials as authorized (marked credentials can be later
+   used by some other functions). If the function was unable to verify the
+   credentials for some reason then it will fail and the script should
+   call www_challenge which will challenge the user again.
 
    Negative codes may be interpreted as follows:
-     * -1  (generic error) - some generic error occurred and no reply was
+     * -1 (generic error) - some generic error occurred and no reply was
        sent out;
-     * -2 (invalid password) - valid user, but wrong password;
+     * -2 (invalid password) - wrong password;
      * -3 (invalid user) - authentication user does not exist.
+     * -4 (nonce expired) - the nonce has expired
+     * -5 (no credentials) - request does not contain an Authorization
+       header with the correct realm.
+     * -6 (nonce reused) - the nonce has already been used to authenticate
+       a previous request
+     * -8 (authuser mismatch) - depending on the method, th From/To/RURI
+       user does not match the authentication user (see auth_check()
+       function).
 
    Meaning of the parameters is as follows:
-     * realm  -  Realm  is  a  opaque  string  that the user agent should
-       present to the user so he can decide what username and password to
-       use. Usually this is domain of the host the server is running on.
-       It  must  not  be empty string "". In case of REGISTER requests To
+     * realm - Realm is a opaque string that the user agent should present
+       to the user so he can decide what username and password to use.
+       Usually this is domain of the host the server is running on.
+       It must not be empty string “�. In case of REGISTER requests To
        header field domain (e.g., variable $td) can be used (because this
-       header  field represents the user being registered), for all other
-       messages  From  header  field  domain  can be used (e.g., variable
-       $fd).
+       header field represents the user being registered), for all other
+       messages From header field domain can be used (e.g., variable $fd).
        The string may contain pseudo variables.
-     * table  -  Table  to  be  used  to  lookup  usernames and passwords
-       (usually subscribers table).
-     * method  - the method to be used for authentication. This parameter
-       is   optional   and  if  not  set  is  the  first  "word"  on  the
-       request-line.
+     * table - Table to be used to lookup usernames and passwords (usually
+       subscribers table).
+     * method - the method to be used for authentication. This parameter
+       is optional and if not set is the first "word" on the request-line.
 
    This function can be used from REQUEST_ROUTE.
 
@@ -354,35 +356,34 @@ if (!www_authorize("kamailio.org", "subscriber")) {
 
 4.2.  www_authorize(realm, table)
 
-   It  is  same  function as www_authenticate(realm, table). This name is
-   kept  for  backward  compatibility,  since it was named this way first
-   time by it actually does user authentication.
+   It is same function as www_authenticate(realm, table). This name is
+   kept for backward compatibility, since it was named this way first time
+   by it actually does user authentication.
 
 4.3.  proxy_authenticate(realm, table)
 
    Name alias: proxy_authorize(realm, table)
 
-   The  function  verifies  credentials  according  to  RFC2617.  If  the
-   credentials  are  verified successfully then the function will succeed
-   and  mark  the  credentials  as  authorized (marked credentials can be
-   later  used  by  some  other functions). If the function was unable to
-   verify  the  credentials  for  some  reason  then it will fail and the
-   script  should  call  proxy_challenge  which  will  challenge the user
-   again.
+   The function verifies credentials according to RFC2617. If the
+   credentials are verified successfully then the function will succeed
+   and mark the credentials as authorized (marked credentials can be later
+   used by some other functions). If the function was unable to verify the
+   credentials for some reason then it will fail and the script should
+   call proxy_challenge which will challenge the user again.
 
    Negative return codes have the same meaning as for www_authenticate().
 
    Meaning of the parameters is as follows:
-     * realm  -  Realm  is  a  opaque  string  that the user agent should
-       present to the user so he can decide what username and password to
-       use. Usually this is domain of the host the server is running on.
-       It  must not be empty string "". Apart of a static string, typical
+     * realm - Realm is a opaque string that the user agent should present
+       to the user so he can decide what username and password to use.
+       Usually this is domain of the host the server is running on.
+       It must not be empty string “�. Apart of a static string, typical
        value is From header field domain (e.g., variable $fd).
-       If  an  empty  string  "" is used then the server will generate it
-       from the request. From header field domain will be used as realm.
+       If an empty string “� is used then the server will generate it from
+       the request. From header field domain will be used as realm.
        The string may contain pseudo variables.
-     * table  -  Table  to  be  used  to  lookup  usernames and passwords
-       (usually subscribers table).
+     * table - Table to be used to lookup usernames and passwords (usually
+       subscribers table).
 
    This function can be used from REQUEST_ROUTE.
 
@@ -395,39 +396,41 @@ if (!proxy_authorize("$fd", "subscriber)) {
 
 4.4.  proxy_authorize(realm, table)
 
-   It  is same function as proxy_authenticate(realm, table). This name is
-   kept  for  backward  compatibility,  since it was named this way first
-   time but it actually does user authentication.
+   It is same function as proxy_authenticate(realm, table). This name is
+   kept for backward compatibility, since it was named this way first time
+   but it actually does user authentication.
 
 4.5.  auth_check(realm, table, flags)
 
-   The  function  combines  the  functionalities  of www_authenticate and
-   proxy_authenticate,  first  being  exectuted  if  the SIP request is a
+   The function combines the functionalities of www_authenticate and
+   proxy_authenticate, first being exectuted if the SIP request is a
    REGISTER, the second for the rest.
 
    In addition, a matter of flags parameter value, the function checks if
-   authentication   username   matches   From/To   header  username,  and
+   authentication username matches From/To header username, and
    Request-URI in case of PUBLISH.
 
+   Negative return codes have the same meaning as for www_authenticate().
+
    Meaning of the parameters is as follows:
-     * realm  -  Realm  is  a  opaque  string  that the user agent should
-       present to the user so he can decide what username and password to
-       use. Usually this is domain of the host the server is running on.
-       It  must not be empty string "". Apart of a static string, typical
+     * realm - Realm is a opaque string that the user agent should present
+       to the user so he can decide what username and password to use.
+       Usually this is domain of the host the server is running on.
+       It must not be empty string “�. Apart of a static string, typical
        value is From header field domain (e.g., variable $fd).
        The string may contain pseudo variables.
-     * table  -  Table  to  be  used  to  lookup  usernames and passwords
-       (usually subscribers table).
+     * table - Table to be used to lookup usernames and passwords (usually
+       subscribers table).
        The string may contain pseudo variables.
-     * flags  - set of flags to control the behaviour of the function. If
+     * flags - set of flags to control the behaviour of the function. If
        it is 1, then the function will check to see if the authentication
-       username  matches  either  To  or  From  header username. REGISTER
-       requests:  From and To must match the authentication user. PUBLISH
-       requests:  From,  To and Request-URI must match the authentication
-       user.   All   other   requests:   From   header   must  match  the
-       authentication user.
-       Additionally  all domains in the checked URIs and the realm in the
-       authentication  header will be checked to match the provided realm
+       username matches either To or From header username. REGISTER
+       requests: From and To must match the authentication user. PUBLISH
+       requests: From, To and Request-URI must match the authentication
+       user. All other requests: From header must match the authentication
+       user.
+       Additionally all domains in the checked URIs and the realm in the
+       authentication header will be checked to match the provided realm
        parameter.
        The string may contain pseudo variables.
 
@@ -443,22 +446,22 @@ if (!auth_check("$fd", "subscriber", "1")) {
 
 4.6.  is_subscriber(uri, dbtable, flags)
 
-   The  function checks if there is a subscriber corresponding to the AoR
-   in   uri   parameter.   It   uses  same  database  connection  as  for
+   The function checks if there is a subscriber corresponding to the AoR
+   in uri parameter. It uses same database connection as for
    authentication functions.
 
-   In   addition,   if   the   subscriber   record  is  found,  then  the
+   In addition, if the subscriber record is found, then the
    load_credentials attributes are loaded. An use case can be loading the
    credential attributes for callee.
 
    Meaning of the parameters is as follows:
      * uri - a valid SIP URI value to identify the subscriber. The string
        may contain pseudo variables.
-     * dbtable  - Table to be used to lookup username and domain from URI
-       (usually   subscriber   table).  The  string  may  contain  pseudo
+     * dbtable - Table to be used to lookup username and domain from URI
+       (usually subscriber table). The string may contain pseudo
        variables.
-     * flags  - set of flags to control the behaviour of the function. If
-       it  is 1, then the function will use the domain part of the URI to
+     * flags - set of flags to control the behaviour of the function. If
+       it is 1, then the function will use the domain part of the URI to
        perform the database table search.
        The parameter may be a pseudo variable.