In that I think this could be one of the first steps to getting that proposal to work, I would say yes. 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+Spec > > 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? > > >
