[SR-Users] bug in authdb_mod ??
jay binks
jaybinks at gmail.com
Mon Dec 9 13:23:24 CET 2013
Ok so... yea I should have waited another 10 min before posting to the
list..
I did the patch... it works for me.
if someone familiar with db_cassandra can clean this up and commit it, I
would be quite grateful.
# git diff dbcassa_base.cpp
diff --git a/modules/db_cassandra/dbcassa_base.cpp
b/modules/db_cassandra/dbcassa_base.cpp
index e9d3a32..155221d 100644
--- a/modules/db_cassandra/dbcassa_base.cpp
+++ b/modules/db_cassandra/dbcassa_base.cpp
@@ -439,6 +439,7 @@ ColumnVecPtr cassa_translate_query(const db1_con_t* _h,
const db_key_t* _k,
int key_len=0, seckey_len = 0;
int no_kc, no_sec_kc;
dbcassa_table_p tbc;
+ char pk[255];
/** Lock table schema and construct primary and secondary key **/
if(_k) {
@@ -495,8 +496,12 @@ ColumnVecPtr cassa_translate_query(const db1_con_t*
_h, const db_key_t* _k,
} else { /* the table doesn't have any secondary key
defined */
if(_c) {
for(int i=0; i< _nc; i++) {
- sp.column_names.push_back(_c[i]->s);
- LM_DBG("Query col: %s\n", _c[i]->s);
+ sprintf(pk, "%.*s", _c[i]->len,
_c[i]->s );
+ sp.column_names.push_back( pk);
+
//sp.column_names.push_back(_c[i]->s);
+ LM_DBG("Query col: %s\n", pk );
+ //LM_DBG("Query col: %s\n",
_c[i]->s);
+ LM_DBG("JAY Query col: %.*s\n",
_c[i]->len, _c[i]->s);
}
LM_DBG("get %d columns\n", _nc);
sp.__isset.column_names = true; // set
yea I know I left crap in there, but it give syou an idea... also...
yea pk is a crap name... copy paste... and I havnt given any thought to the
size 255 , but thats probably fairly safe and anything smaller might not
be so safe.
( unless there is a limit elsewhere I should observe )
Jay
On 9 December 2013 22:14, jay binks <jaybinks at gmail.com> wrote:
> Ok my latest makes me think this is an issue in db_cassandra.
>
> when I add the following debug line it displays as expected.
>
> 496 if(_c) {
> 497 for(int i=0; i< _nc; i++) {
> 498 sp.column_names.push_back(_c[i]->s);
> 499 LM_DBG("Query col: %s\n", _c[i]->s);
> 500 LM_DBG("JAY Query col: %.*s\n", _c[i]->len, _c[i]->s);
> 501 }
> 502 LM_DBG("get %d columns\n", _nc);
> 503 sp.__isset.column_names = true; // set
>
> so _c[i]->s is just going to the end of the string, instead of respecting
> _c[i]->len
>
>
> While I COULD work out a fix for this using sprintf or similar, it would
> probably not be in keeping with kamaiio convention.
> ( since im not experienced with kamailio code )
> Also, im not sure what other places I would miss.
>
> can someone more experienced with kamailio take a look and propose a patch
> for me to test.
>
>
> Thanks
>
> Jay
>
>
>
>
> On 9 December 2013 21:34, jay binks <jaybinks at gmail.com> wrote:
>
>> kamailio -v
>> version: kamailio 4.2.0
>>
>> im still digging, but my current hunch is that my prior diagnosis may be
>> wrong, and this might be in db_cassandra ...
>> still digging, but I will update the list with my findings if they are of
>> interest.
>>
>>
>>
>>
>> On 9 December 2013 21:26, Daniel-Constantin Mierla <miconda at gmail.com>wrote:
>>
>>> What version are you using?
>>>
>>> Daniel
>>>
>>>
>>> On 09/12/13 12:17, jay binks wrote:
>>>
>>>
>>> So when Im trying to use is_subscriber & load_credentials together, It
>>> seems I have either hit a bug or just a bad config ( but I dont think its
>>> the latter )
>>>
>>> My symptom is that only the field on the far right of
>>> "load_credentials" ever returns the correct value, the other fields are
>>> always null.
>>>
>>> My config has this setting :
>>> modparam("auth_db", "load_credentials", "field1;field2")
>>>
>>> and I can see the following debug when running kamailio -ddddd
>>>
>>> 0(14174) DEBUG: auth_db [authdb_mod.c:291]: w_is_subscriber(): uri
>>> [sip: 1112 at 192.168.173.5] table [subscriber] flags [1]
>>> 0(14174) DEBUG: db_cassandra [dbcassa_base.cpp:807]: db_cassa_query():
>>> query table=subscriber
>>> 0(14174) DEBUG: db_cassandra [dbcassa_table.c:461]:
>>> dbcassa_db_get_table(): found dbname=kamailio, table=subscriber
>>> 0(14174) DEBUG: db_cassandra [dbcassa_base.cpp:351]:
>>> cassa_constr_key(): query col = username
>>> 0(14174) DEBUG: db_cassandra [dbcassa_base.cpp:351]:
>>> cassa_constr_key(): query col = domain
>>> 0(14174) DEBUG: db_cassandra [dbcassa_base.cpp:376]:
>>> cassa_constr_key(): key = 1112 192.168.173.5
>>> 0(14174) DEBUG: db_cassandra [dbcassa_base.cpp:499]:
>>> cassa_translate_query(): Query col: field2
>>> 0(14174) DEBUG: db_cassandra [dbcassa_base.cpp:499]:
>>> cassa_translate_query(): Query col: field1; field2
>>> 0(14174) DEBUG: db_cassandra [dbcassa_base.cpp:501]:
>>> cassa_translate_query(): get 2 columns
>>> 0(14174) DEBUG: <core> [db_res.c:118]: db_new_result(): allocate 56
>>> bytes for result set at 0x7fc6ce770e78
>>>
>>> if I had to put money on where the bug is, I would look in parse_aaa_pvs
>>> in authdb_mod.c
>>> however, an initial glance revealed nothing glaring, also this file was
>>> last changed in *2013-01-20 ( and that was only a move from modules_k )*
>>>
>>> SURELY I cant be the only person wanting to use this for more than one
>>> field ?
>>> This code looks like its almost the same as when first committed in
>>> August 2011 ....
>>>
>>> Id love someone to see if they can confirm this and point me in the
>>> right direction ( if this is my fault ) or lets get this fixed, if its a
>>> bug :)
>>>
>>> --
>>> Sincerely
>>>
>>> Jay
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>> --
>>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>
>>
>> --
>> Sincerely
>>
>> Jay
>>
>
>
>
> --
> Sincerely
>
> Jay
>
--
Sincerely
Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20131209/631299c7/attachment-0001.html>
More information about the sr-users
mailing list