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