Summary:	ASTERISK-22900: chan_sip miss parsed realm, if contain @ character
Reporter:	adomjan (adomjan)	Labels:
Date Opened:	2013-11-25 07:01:56.000-0600	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Channels/chan_sip/Interoperability
Versions:	11.6.0 13.18.4	Frequency of Occurrence	Constant
Related Issues:
Environment:	Fedora 19	Attachments:	( 0) chan_sip.c-fix_at_in_realm.patch
Description:	The sip proxy use srxadmin@localhost realm. in sip.conf auth => user:secret@srxadmin@localhost asterisk parse localhost as realm. According: http://tools.ietf.org/html/rfc2617#section-3.2.1 the @ character permited in realm string.
Comments:	By: Matt Jordan (mjordan) 2013-11-25 09:15:14.273-0600 While the patch is correct - we should certainly be separating the username portion (which includes the secret) from the realm by splitting the string at the first occurrence of '@' as opposed to the last - I'm a bit concerned that not all callers of {{add_realm_authentication}} will have properly escaped the '@' character from the username. In particular, people who had previously defined a SIP peer with the following: {noformat} auth=mark:top@secret@digium.com {noformat} Would have had their authentication "work" (or at the least, it would have correctly split out the realm from the username portion), even if it is incorrect to contain an unescaped '@' character in the username portion. I don't see {{chan_sip}} escaping the username/password portion at any point where it uses the authentication information, so providing an unescaped '@' in the password would most likely break regardless. However, given how finicky URI parsing can be, I'd prefer there to be some amount of testing done on this patch before it goes in. By: adomjan (adomjan) 2013-11-25 09:59:19.036-0600 Correct solution could be to introduce another format like: authuser:secret:md5secret:realm By: Matt Jordan (mjordan) 2013-11-26 12:35:31.875-0600 No - I don't think that would be allowable. Since this is a bug, I'll move this over to the Open column, but I'm a bit concerned about unilaterally changing the URI parsing here without some unit testing. By: adomjan (adomjan) 2013-11-27 16:28:00.387-0600 I think could left the strrchr() and apply urldecode for the realm part?