Yes, that seems to be a common theme amongst anything with an oauth label in the code base :).
It's also strange that this stuff is in an oauth package, despite only a small number of classes actually having anything to do with oauth. On Thu, Aug 28, 2008 at 1:45 AM, Ian Boston <[EMAIL PROTECTED]> wrote: > On that subject, I did notice low coverage of some of the oauth areas in > social-api, when checking some other things. > > eg > http://people.apache.org/~ieb/shindig/shindig-parent/shindig-social-<http://people.apache.org/%7Eieb/shindig/shindig-parent/shindig-social-> > api/cobertura/index.html > > This isn't a request for you to write unit tests as part of the move, just > a note that coverage is low. > Ian > > On 28 Aug 2008, at 01:22, Kevin Brown wrote: > > To simplify the gadget rendering code paths that deal with security >> tokens, >> I'm going to be moving the social api auth filters up into common (next to >> the security tokens...we may want to put these in common.security or >> common.auth or something). >> >> This will just be a package rename for the filter, AuthenticationHandler, >> and the handler that converts parameter-form security tokens. The oauth >> handler will stay in the social code base for the time being as there >> isn't >> any obvious near term requirement to support oauth during gadget >> rendering. >> >> This is in conjunction with SHINDIG-523 and SHINDIG-517. >> > >
