+1 On Thu, Aug 23, 2012 at 9:28 AM, daviesd <davi...@oclc.org> wrote:
> +1 > > > On 8/23/12 9:23 AM, "Dan Dumont" <ddum...@apache.org> wrote: > > > Well how about a vote on a revised option 1? > > > > +1 Refactor oauthpopup, add new oauthpopup to CommonContainer dep list, > > note to all other container users in upgrade file. > > > > 0 I don't care > > > > -1 Leave my oauthpopup alone! > > > > On Wed, Aug 22, 2012 at 8:17 PM, Dan Dumont <ddum...@apache.org> wrote: > > > >> Not sure I like this proposal. To me, it doesn't make sense to have an > >> auth interface that is not the remote site... > >> Would make it too easy to spoof an oauth endpoint and steal passwords. > >> > >> > >> On Wed, Aug 22, 2012 at 4:16 PM, Franklin, Matthew B. < > mfrank...@mitre.org > >>> wrote: > >> > >>>> -----Original Message----- > >>>> From: Dan Dumont [mailto:ddum...@apache.org] > >>>> Sent: Wednesday, August 22, 2012 3:47 PM > >>>> To: dev@shindig.apache.org > >>>> Subject: Re: Changing oauthpopup feature to introduce some container > >>>> cooperation... > >>>> > >>>> In that I think this could be one of the first steps to getting that > >>>> proposal to work, I would say yes. > >>> > >>> There is an alternative proposal under discussion that makes sense for > >>> the 3.0 timeframe that involves rendering an oAuth authorization view > if > >>> the correct token is not found. > >>> > >>>> If the container launches the auth request, we would have a way to do > it > >>>> before a render. It certainly would need more work, but it's a start. > >>>> > >>>> On Wed, Aug 22, 2012 at 2:17 PM, daviesd <davi...@oclc.org> wrote: > >>>> > >>>>> Does this > >>>>> > >>>>> > >>>> > http://docs.opensocial.org/display/OSD/Fixing+OAuth+in+Core+Gadget+Spe > >>>> c > >>>>> > >>>>> Come into play at all? > >>>>> > >>>>> doug > >>>>> > >>>>> > >>>>> On 8/21/12 11:17 AM, "Dan Dumont" <ddum...@us.ibm.com> wrote: > >>>>> > >>>>>> I've been looking at having the oauth popup feature make some calls > >>> into > >>>>>> the container over rpc to handle the popup for various reasons, one > >>> of > >>>>>> which is to work around browser popup blockers. > >>>>>> The container could implement the feature as a litebox instead of a > >>>>> popup. > >>>>>> > >>>>>> This change though requires some changes that will probably break > >>>>>> unsuspecting upgraders... so my options are as follows: > >>>>>> > >>>>>> 1) Refactor oauthpopup and break unsuspecting containers when they > >>>>>> upgrade. > >>>>>> 2) Refactor oauthpopup and add it to core (it's pretty small) so > >>> that no > >>>>>> one gets hurt on the upgrade. > >>>>>> 3) Refactor oauthpopup and add only the container part to core (this > >>> gets > >>>>>> kinda messy... ) > >>>>>> 4) LEAVE MY OAUTHPOPUP ALONE! (mess with my own copy, but don't > >>>> change > >>>>>> shindig) > >>>>>> Btw, the default implementation in my refactor calls window.open > just > >>>>> like > >>>>>> the old one, only now the container is doing the window.open instead > >>> of > >>>>>> the gadget. > >>>>>> > >>>>>> What does the community think the best approach would be? > >>>>> > >>>>> > >>>>> > >>> > >> > >> > > >
