[OpenSIPS-Users] auth_db module in 3.2.2

[Adrian Georgescu]

After removing the ha1b column, I am now getting the following errors and authentication does not work:

Aug 12 20:51:59 live01 /usr/sbin/opensips[10064]: ERROR:db_mysql:db_mysql_store_result: driver error: Commands out of sync; you can't run this command now
Aug 12 20:51:59 live01 /usr/sbin/opensips[10064]: ERROR:auth_db:get_ha1: failed to query database
Aug 12 20:52:00 live01 /usr/sbin/opensips[10057]: ERROR:db_mysql:db_mysql_store_result: driver error: Commands out of sync; you can't run this command now
Aug 12 20:52:00 live01 /usr/sbin/opensips[10057]: ERROR:auth_db:get_ha1: failed to query database

auth_db module configuration:

modparam("auth_db", "calculate_ha1",     0)
modparam("auth_db", "password_column",   "ha1")
modparam("auth_db", "user_column",       "username")
modparam("auth_db", "domain_column",     "domain”)

What can be the reason for this?

Regards,
Adrian



> On 12 Aug 2021, at 13:04, Liviu Chircu <liviu at opensips.org> wrote:
> 
> On 12.08.2021 18:36, Adrian Georgescu wrote:
>> The auth_db module has some dramatic changes which are either undocumented or not backwards compatible and is unclear how to handle this.
>> 
>> https://opensips.org/docs/modules/3.1.x/auth_db.html#param_password_column_2 <https://opensips.org/docs/modules/3.1.x/auth_db.html#param_password_column_2>Hi Adrian,
> 
> Indeed, with the addition of RFC 8760 support (support for SHA-256 and SHA-512-256 auth algorithms), me and Maksym Sobolyev decided to try and remove the "ha1b" feature, originally designed to accommodate some broken SIP UAs who cannot follow the basic SIP authentication spec.  The feature had been in there since the very beginnings, and we were not sure if anyone is really benefiting from it anymore nowadays.
> 
> A strong reason for removing "ha1b" was the sheer number of hashes to be stored per subscriber.  Since we now have 3 algorithms (MD5, SHA-256, SHA-512-256), there are 3 hash-columns to store.  With the "ha1b" feature, there would be 2 x 3 = 6 hashes in total to store, per user.  So you can see where this is going: "Can we get away with dropping ha1b and storing half the data per user?" ... was the big question.
> 
> Still, we agreed that if there is still enough traction for the "ha1b" feature from the community, we can easily re-add the ha1b logic and 3 more columns to the table and backport everything to 3.2.  It's a trivial task, frankly.
> 
> The big question is: on your platform(s), can you control the software in all SIP UAs that incorrectly include "realm" information in the "username" field (which should really be just the user's name!) and fix the problem on the phone side?
> 
> PS: I noticed the 3.2 migration page is missing any info on ha1b.  Will get it fixed soon, depending on the outcome of the discussion.
> 
> Best Regards,
> 
> -- 
> Liviu Chircu
> www.twitter.com/liviuchircu <http://www.twitter.com/liviuchircu> | www.opensips-solutions.com <http://www.opensips-solutions.com/>
> OpenSIPS Summit 2021 Distributed | www.opensips.org/events <http://www.opensips.org/events>_______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20210812/e567bbc3/attachment.html>