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