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