functions.xml 3.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
  3. "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
  4. <section id="auth_db.functions" xmlns:xi="http://www.w3.org/2001/XInclude">
  5. <sectioninfo>
  6. </sectioninfo>
  7. <title>Functions</title>
  8. <section id="www_authorize">
  9. <title><function>www_authorize(realm, table)</function></title>
  10. <para>
  11. The function verifies credentials according to RFC2617. If the
  12. credentials are verified successfully then the function will
  13. succeed and mark the credentials as authorized (marked credentials
  14. can be later used by some other functions). If the function was
  15. unable to verify the credentials for some reason then it will fail
  16. and the script should call <function>www_challenge</function> which
  17. will challenge the user again.
  18. </para>
  19. <para>Meaning of the parameters is as follows:</para>
  20. <itemizedlist>
  21. <listitem>
  22. <formalpara>
  23. <title>realm</title>
  24. <para>
  25. Realm is a opaque string that the user agent should
  26. present to the user so he can decide what username and
  27. password to use. Usually this is domain of the host the
  28. server is running on. If an empty string "" is used
  29. then the server will generate it from the request. In
  30. case of REGISTER requests To header field domain will
  31. be used (because this header field represents a user
  32. being registered), for all other messages From header
  33. field domain will be used.
  34. </para>
  35. </formalpara>
  36. </listitem>
  37. <listitem>
  38. <formalpara>
  39. <title>table</title>
  40. <para>
  41. Table to be used to lookup usernames and passwords
  42. (usually subscribers table).
  43. </para>
  44. </formalpara>
  45. </listitem>
  46. </itemizedlist>
  47. <example>
  48. <title><function moreinfo="none">www_authorize</function> usage</title>
  49. <programlisting>
  50. ...
  51. if (www_authorize("iptel.org", "subscriber")) {
  52. www_challenge("iptel.org", "1");
  53. };
  54. ...
  55. </programlisting>
  56. </example>
  57. </section>
  58. <section id="proxy_authorize">
  59. <title><function>proxy_authorize(realm, table)</function></title>
  60. <para>
  61. The function verifies credentials according to RFC2617. If the
  62. credentials are verified successfully then the function will
  63. succeed and mark the credentials as authorized (marked credentials
  64. can be later used by some other functions). If the function was
  65. unable to verify the credentials for some reason then it will fail
  66. and the script should call <function>proxy_challenge</function>
  67. which will challenge the user again.
  68. </para>
  69. <para>Meaning of the parameters is as follows:</para>
  70. <itemizedlist>
  71. <listitem>
  72. <para>
  73. <emphasis>realm</emphasis> - Realm is a opaque string that
  74. the user agent should present to the user so he can decide
  75. what username and password to use. Usually this is domain
  76. of the host the server is running on.
  77. </para>
  78. <para>
  79. If an empty string "" is used then the server will generate
  80. it from the request. From header field domain will be used
  81. as realm.
  82. </para>
  83. </listitem>
  84. <listitem>
  85. <para>
  86. <emphasis>table</emphasis> - Table to be used to lookup
  87. usernames and passwords (usually subscribers table).
  88. </para>
  89. </listitem>
  90. </itemizedlist>
  91. <example>
  92. <title>proxy_authorize usage</title>
  93. <programlisting>
  94. ...
  95. if (!proxy_authorize("", "subscriber)) {
  96. proxy_challenge("", "1"); # Realm will be autogenerated
  97. };
  98. ...
  99. </programlisting>
  100. </example>
  101. </section>
  102. </section>