Re: [reSIProcate] qop Parameter Parsing
Zsolt,
in fact this is not a nice solution. We are using the ServerAuthManager and the
kind of fix you are suggesting would need to be implemented in
ServerAuthManager.cxx.
Currently, we are subclassing ServerAuthmanager:: and copying the qopOptions
parameter to a qop parameter (if the first exists and the latter doesn't)
before calling the base class method. Same like with your solution: It's not
really nice and it should really be fixed in the stack.
Best regards,
Matthias Moetje
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of
> Rizsányi Zsolt
> Sent: Samstag, 27. Januar 2007 13:36
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] qop Parameter Parsing
>
> On Monday 22 January 2007, Byron Campen wrote:
> > Ok, the problem here is that what we expect to follow qop= is
> > context-sensitive; in an Authorization-type header, we expect to find
> > a qop-value (a non-quoted token), but in an Authenticate-type header,
> > we expect to see a qop-options (a quoted, comma delimited, sequence
> > of tokens). Unfortunately, there is currently no way to make the
> > parse code context-sensitive. The API for Parameter would need to
> > change (right now, it just looks for a quote, and if it is there, it
> > assumes we were looking for a qop-options). Additionally, both
> > Authorization-type and Authenticate-type are the same class (Auth),
> > so it is doubtful that this context info is even availabe in the
> > first place. Any opinions on how we can make this code context-
> > sensitive with minimal impact on the rest of the code?
>
> We have encountered this issue and we have fixed it simply from the
> stack
> using code which knows its context. Here is an example:
>
> if (auth.exists(resip::p_qop))
> qop = auth.param(resip::p_qop).c_str();
> else if (auth.exists(resip::p_qopOptions))
> qop = auth.param(resip::p_qopOptions).c_str();
> else
> qop = "";
>
> It's probably not the nicest solution but I it can be implemented
> easily
> and it can be used until a better solution is found.
>
> Regards,
> Zsolt
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel