+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? >>>>> >>>>> >>>>> >>> >> >>
