+1 On Aug 23, 2012 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? > >> >> > >> >> > >> >> > >> > > > > >
