Re: [reSIProcate] qop Parameter Parsing

[Byron Campen <bcampen@xxxxxxxxxxxx>]

	So, I have code in a working copy that stores both qop and  
qopOptions as DataParameters. While parsing from a HeaderFieldValue,  
Auth.cxx will check its Headers::Type when it encounters something  
that parsed as qop (ie; begins with "qop="); if it is either a  
WWWAuthenticate or ProxyAuthenticate, it will set the  
DataParameter::mQuoted to true, and set the parameter's type to  
qopOptions. Otherwise, it will set DataParameter::mQuoted to false,  
and the type to qop. From then on, the two parameter types are stored  
separately, and accessed with param(p_qop) and param(p_qopOptions).  
If you end up _creating_ a qop param with param(p_qop) or param 
(p_qopOptions), it will automatically do the right thing with regard  
to setting the quotedness. Using operator= (a'la auth.param(p_qop) 
="auth"; or auth.param(p_qopOptions)="auth";) will also do the right  
thing.

	I am thinking that I will put this in a branch, since the current  
parameter-handling code is arcane, _particularly_ with regard to qop.

Best regards,
Byron Campen

> 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
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

Attachment: smime.p7s
Description: S/MIME cryptographic signature