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

Re: [reSIProcate] qop Parameter Parsing


..lol, alright, hope this will be confirmed to be stable soon, then!

Matthias


> -----Original Message-----
> From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
> Sent: Montag, 12. Februar 2007 21:58
> To: Matthias Moetje
> Cc: Rizsányi Zsolt; resiprocate-devel
> Subject: 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
> >