Hello dev team,
I'm trying to compile app_python under kamailio 3.3.2 and gcc (Debian
4.7.2-4) 4.7.2 and I'm getting a bunch of warnings like:
CC (gcc) [M app_python.so] python_exec.o
CC (gcc) [M app_python.so] python_iface.o
In file included from /usr/include/python2.7/Python.h:8:0,
from python_iface.c:28:
/usr/include/python2.7/pyconfig.h:1161:0: warning: "_POSIX_C_SOURCE"
redefined [enabled by default]
In file included from /usr/include/i386-linux-gnu/sys/types.h:26:0,
from ../../route_struct.h:45,
from ../../action.h:42,
from python_iface.c:23:
/usr/include/features.h:214:0: note: this is the location of the previous
definition
CC (gcc) [M app_python.so] python_mod.o
In file included from /usr/include/python2.7/Python.h:8:0,
from python_iface.h:26,
from python_mod.c:27:
/usr/include/python2.7/pyconfig.h:1161:0: warning: "_POSIX_C_SOURCE"
redefined [enabled by default]
In file included from /usr/include/dlfcn.h:23:0,
from ../../sr_module.h:60,
from python_mod.c:24:
/usr/include/features.h:214:0: note: this is the location of the previous
definition
...
According to the Python documentation (
http://docs.python.org/c-api/intro.html#includes), the include directive
for “Python.h” should appear first in the C/C++ file.
It doesn’t sound like a good idea to require this, but if you don’t put
“Python.h” first, you might get compiler warnings like I mentioned above.
I've made a diff (against kamailio-3.3.2) for fixing that.
See attached.
Module: sip-router
Branch: master
Commit: 25600feab7d5d3b30420a05fd4c899f0bbbff667
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=25600fe…
Author: Olle E. Johansson <oej(a)edvina.net>
Committer: Olle E. Johansson <oej(a)edvina.net>
Date: Sun Dec 2 21:24:13 2012 +0100
auth: Documentation corrections
---
modules/auth/doc/auth.xml | 4 ++--
modules/auth/doc/functions.xml | 24 ++++++++++++------------
modules/auth/doc/params.xml | 4 ++--
3 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/modules/auth/doc/auth.xml b/modules/auth/doc/auth.xml
index bf87b47..59cfd9e 100644
--- a/modules/auth/doc/auth.xml
+++ b/modules/auth/doc/auth.xml
@@ -51,10 +51,10 @@
authentication backends).
</para>
<para>
- We decided to break the authentication code into several modules
+ We decided to divide the authentication code into several modules
because there are now more than one backends (currently database
authentication and radius are supported). This allows us to create
- separate packages so uses can install and load only required
+ separate packages so users can install and load only the required
functionality. This also allows us to avoid unnecessary
dependencies in the binary packages.
</para>
diff --git a/modules/auth/doc/functions.xml b/modules/auth/doc/functions.xml
index eee1f56..4140f8c 100644
--- a/modules/auth/doc/functions.xml
+++ b/modules/auth/doc/functions.xml
@@ -9,7 +9,7 @@
<section id="consume_credentials">
<title><function>consume_credentials()</function></title>
<para>
- This function removes previously authorized credentials from the
+ This function removes previously authorized credential headers from the
message being processed by the server. That means that the
downstream message will not contain credentials there were used by
this server. This ensures that the proxy will not reveal
@@ -73,7 +73,7 @@ if (has_credentials("myrealm")) {
</para>
<para>
It must not be empty string <quote></quote>. In case of REGISTER
- requests To header field domain (e.g., variable $td) can be used
+ requests, the 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).
@@ -132,10 +132,10 @@ if (!www_authenticate("$td", "subscriber")) {
put the header field into a response generated from the request the
server is processing and send the reply. Upon reception of such a
reply the user agent should compute credentials and retry the request.
- For more information regarding digest authentication see RFC2617. See module parameter force_stateless_reply
- regarding sending of the reply.
+ For more information regarding digest authentication see RFC2617.
+ See module parameter force_stateless_reply regarding sending of the reply.
</para>
- <para>Meaning of the parameters the same as for function
+ <para>Meaning of the parameters is the same as for function
www_challenge(realm, flags)</para>
<para>
This function can be used from REQUEST_ROUTE.
@@ -160,7 +160,7 @@ if (!proxy_authenticate("$fd", "subscriber")) {
The function challenges a user agent for authentication. It combines
the functions www_challenge() and proxy_challenge(), by calling
internally the first one for REGISTER requests and the second one for
- the rest of the request types.
+ the rest of other request types.
</para>
<para>Meaning of the parameters the same as for function
www_challenge(realm, flags)</para>
@@ -168,7 +168,7 @@ if (!proxy_authenticate("$fd", "subscriber")) {
This function can be used from REQUEST_ROUTE.
</para>
<example>
- <title>proxy_challenge usage</title>
+ <title>auth_challenge usage</title>
<programlisting format="linespecific">
...
if (!auth_check("$fd", "subscriber", "1")) {
@@ -240,7 +240,7 @@ if (!auth_check("$fd", "subscriber", "1")) {
</listitem>
<listitem>
<para><emphasis>passwd</emphasis> - the password to be used
- for authentication. Can contain config variables. Username is
+ for authentication. Can contain config variables. The Username is
taken from Auth header.</para>
</listitem>
<listitem>
@@ -278,7 +278,7 @@ if (!auth_check("$fd", "subscriber", "1")) {
</itemizedlist>
<para>
When challenge header is built and stored in avp,
- append_to_reply() and sl reply functions can be used to send
+ append_to_reply() and the sl reply functions can be used to send
appropriate SIP reply to challenge for authentication.
</para>
<para>
@@ -356,7 +356,7 @@ if (!pv_proxy_authenticate("$fd", "$avp(password)", "0")) {
This function can be used from REQUEST_ROUTE.
</para>
<example>
- <title>pv_proxy_authenticate usage</title>
+ <title>pv_auth_check usage</title>
<programlisting format="linespecific">
...
$avp(password)="xyz";
@@ -370,10 +370,10 @@ if (!pv_auth_check("$fd", "$avp(password)", "0", "1")) {
<section id="auth_get_www_authenticate">
<title>
- <function moreinfo="none">auth_get_www_authenticate(realm, flags, pvdst)</function>
+ <function moreinfo="none">auth_get_www_authenticate(realm, flags, pvdest)</function>
</title>
<para>
- Build WWW-Authentication header and set the resulting value in 'pvdest' parameter.
+ Build WWW-Authentication header and set the resulting value in 'pvdest' pseudo-variable parameter.
</para>
<para>Meaning of the realm and flags parameters is the same as for
pv_www_authenticate(realm, passwd, flags)</para>
diff --git a/modules/auth/doc/params.xml b/modules/auth/doc/params.xml
index f9c1f8a..973f14e 100644
--- a/modules/auth/doc/params.xml
+++ b/modules/auth/doc/params.xml
@@ -13,8 +13,8 @@
<varname>auth_checks_in_dlg</varname> (flags)
</title>
<para>
- These three module parameters control which optional integrity
- checks will be performed on the SIP message carrying digest response
+ These three module parameters control which optional integrity
+ checks will be performed on the SIP message carrying digest response
during digest authentication. <varname>auth_check_register</varname>
controls integrity checks to be performed on REGISTER messages,
<varname>auth_checks_no_dlg</varname> controls which optional
Module: sip-router
Branch: master
Commit: 9b67242978cb6aab702ccf4715e9152ac8f719c8
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=9b67242…
Author: Olle E. Johansson <oej(a)edvina.net>
Committer: Olle E. Johansson <oej(a)edvina.net>
Date: Sun Dec 2 21:26:54 2012 +0100
auth: README update
---
modules/auth/README | 35 ++++++++++++++++++-----------------
1 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/modules/auth/README b/modules/auth/README
index a429a53..5a76ca6 100644
--- a/modules/auth/README
+++ b/modules/auth/README
@@ -50,7 +50,7 @@ Daniel-Constantin Mierla
1.4.6. pv_www_authenticate(realm, passwd, flags [, method])
1.4.7. pv_proxy_authenticate(realm, passwd, flags)
1.4.8. pv_auth_check(realm, passwd, flags, checks)
- 1.4.9. auth_get_www_authenticate(realm, flags, pvdst)
+ 1.4.9. auth_get_www_authenticate(realm, flags, pvdest)
1.1. Overview
@@ -59,10 +59,10 @@ Daniel-Constantin Mierla
all other authentication related modules (so called authentication
backends).
- We decided to break the authentication code into several modules
+ We decided to divide the authentication code into several modules
because there are now more than one backends (currently database
authentication and radius are supported). This allows us to create
- separate packages so uses can install and load only required
+ separate packages so users can install and load only the required
functionality. This also allows us to avoid unnecessary dependencies in
the binary packages.
@@ -540,7 +540,7 @@ modparam("auth", "use_domain", 1)
1.4.1. consume_credentials()
- This function removes previously authorized credentials from the
+ This function removes previously authorized credential headers from the
message being processed by the server. That means that the downstream
message will not contain credentials there were used by this server.
This ensures that the proxy will not reveal information about
@@ -582,10 +582,11 @@ if (has_credentials("myrealm")) {
* 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).
+ It must not be empty string "". In case of REGISTER requests, the
+ 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).
The string may contain pseudo variables.
* flags - Value of this parameter can be a bitmask of following:
+ 1 - build challenge header with qop=auth
@@ -614,8 +615,8 @@ if (!www_authenticate("$td", "subscriber")) {
information regarding digest authentication see RFC2617. See module
parameter force_stateless_reply regarding sending of the reply.
- Meaning of the parameters the same as for function www_challenge(realm,
- flags)
+ Meaning of the parameters is the same as for function
+ www_challenge(realm, flags)
This function can be used from REQUEST_ROUTE.
@@ -631,14 +632,14 @@ if (!proxy_authenticate("$fd", "subscriber")) {
The function challenges a user agent for authentication. It combines
the functions www_challenge() and proxy_challenge(), by calling
internally the first one for REGISTER requests and the second one for
- the rest of the request types.
+ the rest of other request types.
Meaning of the parameters the same as for function www_challenge(realm,
flags)
This function can be used from REQUEST_ROUTE.
- Example 20. proxy_challenge usage
+ Example 20. auth_challenge usage
...
if (!auth_check("$fd", "subscriber", "1")) {
auth_challenge("$fd", "1");
@@ -675,7 +676,7 @@ if (!auth_check("$fd", "subscriber", "1")) {
messages From header field domain can be used (e.g., varibale $fd).
The string may contain pseudo variables.
* passwd - the password to be used for authentication. Can contain
- config variables. Username is taken from Auth header.
+ config variables. The Username is taken from Auth header.
* flags - the value of this parameter can be a bitmask of following:
+ 1 - the value of password parameter is HA1 format
+ 2 - build challenge header with no qop and add it to avp
@@ -686,7 +687,7 @@ if (!auth_check("$fd", "subscriber", "1")) {
is optional and if not set is the first "word" on the request-line.
When challenge header is built and stored in avp, append_to_reply() and
- sl reply functions can be used to send appropriate SIP reply to
+ the sl reply functions can be used to send appropriate SIP reply to
challenge for authentication.
This function can be used from REQUEST_ROUTE.
@@ -738,7 +739,7 @@ if (!pv_proxy_authenticate("$fd", "$avp(password)", "0")) {
This function can be used from REQUEST_ROUTE.
- Example 23. pv_proxy_authenticate usage
+ Example 23. pv_auth_check usage
...
$avp(password)="xyz";
if (!pv_auth_check("$fd", "$avp(password)", "0", "1")) {
@@ -746,10 +747,10 @@ if (!pv_auth_check("$fd", "$avp(password)", "0", "1")) {
};
...
-1.4.9. auth_get_www_authenticate(realm, flags, pvdst)
+1.4.9. auth_get_www_authenticate(realm, flags, pvdest)
Build WWW-Authentication header and set the resulting value in 'pvdest'
- parameter.
+ pseudo-variable parameter.
Meaning of the realm and flags parameters is the same as for
pv_www_authenticate(realm, passwd, flags)