git:4.1: core/parser: handle the case when username field in auth header has proto scheme
Module: sip-router Branch: 4.1 Commit: e70df7338330f2d3248c7ec0b6d81ff0f188617b URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=e70df733...
Author: Daniel-Constantin Mierla miconda@gmail.com Committer: Daniel-Constantin Mierla miconda@gmail.com Date: Fri Jan 24 15:43:59 2014 +0100
core/parser: handle the case when username field in auth header has proto scheme
- some phones put there "sip:username@domain", so far it was handling "username" and "username@domain"
(cherry picked from commit e56ff0e6a5745321c6a4a5f362cc728177acef0d)
---
parser/digest/digest_parser.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/parser/digest/digest_parser.c b/parser/digest/digest_parser.c index 6e4adce..08683d7 100644 --- a/parser/digest/digest_parser.c +++ b/parser/digest/digest_parser.c @@ -275,6 +275,7 @@ static inline void parse_username(struct username* _u) _u->user = _u->whole; if (_u->whole.len <= 2) return;
+ /* get domain - it can be: username@domain */ d = q_memchr(_u->whole.s, '@', _u->whole.len);
if (d) { @@ -282,6 +283,13 @@ static inline void parse_username(struct username* _u) _u->domain.len = _u->whole.len - (d - _u->whole.s) - 1; _u->user.len = d - _u->user.s; } + + /* get user - it can be: sip:username@domain */ + d = q_memchr(_u->user.s, ':', _u->user.len); + if (d) { + _u->user.len = _u->user.s + _u->user.len - d - 1; + _u->user.s = d + 1; + } }
On 06/03/14 03:40, Juha Heinanen wrote:
Some devices uses user@domain for username part of the authorization header, which I guess is not allowed as well. But we support it for long time, the reason of having ha1 and ha1b in subscriber table. Now I discovered that some snom puts even sip: in front of usern@domain when doing xcap operations. So it is just a safety check, skipping the scheme if it is, otherwise authentication fails. The parser in that part is not a full uri parser, it uses char find.
Daniel
On 07/03/14 22:43, Juha Heinanen wrote:
It is a fix of extracting the proper authentication username, otherwise the value of the user field for authentication is 'sip:xyz...', which is clear an invalid sip username format.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Juha Heinanen