[reSIProcate] qop Parameter Parsing

Byron Campen bcampen at estacado.net
Mon Feb 12 14:21:31 CST 2007


	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 at list.resiprocate.org
>> [mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf Of
>> Rizsányi Zsolt
>> Sent: Samstag, 27. Januar 2007 13:36
>> To: resiprocate-devel at list.resiprocate.org
>> 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 at list.resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070212/246b7c2c/attachment.bin>


More information about the resiprocate-devel mailing list