reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] qop Parameter Parsing

I think it best to proceed with caution. This is because the current qop code is known or understood by very few; mysterious; secret; obscure; esoteric (credit to Dictionary.com). 

Best regards,
Byron Campen


Sounds good. Why not put it into the main branch?
(I don't know the word "arcane"..)

Matthias



-----Original Message-----
From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
Sent: Montag, 12. Februar 2007 21:22
To: Matthias Moetje
Cc: Rizsányi Zsolt; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] qop Parameter Parsing

        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