-
Notifications
You must be signed in to change notification settings - Fork 564
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong password column used for authentication #6
Comments
I've found the problem in modules/auth_db/authorize.c:get_ha1. There should be two prepared statement variables in the function. One for the ha1 statement and a second for the ha1b statement. Right now there is only one prepared statement variable (static db_ps_t auth_ps) so after the function is called once it sets which result column will be returned no matter which one is passed in on future calls. |
…ent queries in the same time. Credits for reporting the bug and the problem go to Steve Brisson Closes issue #6 on GH.
Hi, thanks a lot for your report and troubleshooting - indeed, there was a case which was never considered, leading to using 2 different types of queries in the same time. I made a fix on the trunk version (see 8d74b95 or 8d74b95). Could you please validate my fix before doing the backport to 1.9 and 1.8 ? Thanks and regards, |
I have verified that the fix works correctly. Thanks! |
…ent queries in the same time. Credits for reporting the bug and the problem go to Steve Brisson Closes issue #6 on GH.
Thanks, all backports done ! |
Case OpenSIPS#6 and Case OpenSIPS#7 to fail instead. Improve test_parse_authenticate_body() logic: don't run checks if test fail. GC stray debug output.
Case OpenSIPS#6 and Case OpenSIPS#7 to fail instead. Improve test_parse_authenticate_body() logic: don't run checks if test fail. GC stray debug output.
OpenSIPS branch 1.8
I am running into the same issue as described in bug #477. Are there any updates on this issue? I am having trouble finding the problem in the code as I am unfamiliar with the db/auth modules. It could be a while before I find a solution. Thanks for any support you can give me.
Description: When I authenticate two clients (one client with the digest username: "user1", and the other with the username: "user2@sip.domain.com"), the second client authentication fails. From debug messages, it seems that once a password column is used once (ha1 or ha1b), it will be used in all following queries even if the other password column should be used.
Relevant debug:
First authentication (Success, generates new query) :
DBG:auth_db:get_ha1: username: user2
DBG:auth_db:get_ha1: domain portion: sip.domain.com
DBG:auth_db:get_ha1: calc_ha1: 0
DBG:auth_db:get_ha1: using pass column 2 ha1b
DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7f674f42ec98 (tail=140081688144552) MC=0x7f674f430ee8
DBG:db_mysql:db_mysql_do_prepared_query: new query=|select ha1b from subscriber where username=? AND domain=?|
DBG:db_mysql:re_init_statement: query is , ptr=(nil) DBG:db_mysql:db_mysql_do_prepared_query: new statement(0x7f674f441238) on connection: (0x7f674f42ec98) 0x7f674f42eaa8 DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run DBG:db_mysql:db_mysql_val2bind: added val (0): len=8; type=254; is_null=0 DBG:db_mysql:db_mysql_val2bind: added val (1): len=14; type=254; is_null=0 DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1 columns in result DBG:db_mysql:db_mysql_do_prepared_query: doing to BIND_PARAM out ... DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f674f440ef8 DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f674f440f40 DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f674f440f48)[0]=[ha1b] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type DBG:core:db_allocate_rows: allocate 48 bytes for result rows and values at 0x7f674f440f78 DBG:db_mysql:db_mysql_str2val: converting STRING [a05a32187aab07c37c874b311bf5cc36] DBG:auth:check_response: our result = '416f60b359e7e74f6c427044addd80c1' DBG:auth:check_response: authorization is OK Second authentication (Failure, note that no new query is prepared and the result column name is ha1b) : DBG:auth_db:get_ha1: username: user1 DBG:auth_db:get_ha1: domain portion: DBG:auth_db:get_ha1: calc_ha1: 0 DBG:auth_db:get_ha1: using pass column 1 ha1 DBG:db_mysql:has_stmt_ctx: ctx found for subscriber DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7f674f42ec98 (tail=140081688144552) MC=0x7f674f430ee8 DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run DBG:db_mysql:db_mysql_val2bind: added val (0): len=8; type=254; is_null=0 DBG:db_mysql:db_mysql_val2bind: added val (1): len=14; type=254; is_null=0 DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1 columns in result DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f674f440cf8 DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f674f440f40 DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f674f440f48)[0]=[ha1b] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type DBG:core:db_allocate_rows: allocate 48 bytes for result rows and values at 0x7f674f441940 DBG:db_mysql:db_mysql_str2val: converting STRING [a05a32187aab07c37c874b311bf5cc36] DBG:auth:check_response: our result = 'bc17e12c512d25b469d6d131221b2ee9' DBG:auth:check_response: authorization failed
The text was updated successfully, but these errors were encountered: