passwords.
>>
>>
>> On Wed, Aug 22, 2012 at 4:16 PM, Franklin, Matthew B. > > wrote:
>>
>>> >-Original Message-
>>> >From: Dan Dumont [mailto:ddum...@apache.org]
>>> >Sent: Wednesday, August 22, 2012 3:47 PM
>>> >To
+1
>-Original Message-
>From: Dan Dumont [mailto:ddum...@apache.org]
>Sent: Thursday, August 23, 2012 9:24 AM
>To: Dan Dumont
>Cc: dev@shindig.apache.org
>Subject: Re: Changing oauthpopup feature to introduce some container
>cooperation...
>
>Well how about a
>>> 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 oau
d steal passwords.
>>
>>
>> On Wed, Aug 22, 2012 at 4:16 PM, Franklin, Matthew B. >> wrote:
>>
>>>> -Original Message-
>>>> From: Dan Dumont [mailto:ddum...@apache.org]
>>>> Sent: Wednesday, August 22, 2012 3:47 PM
>>&
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]
> >> >Se
-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...
>> >
>&
Yeah, for 2 I would be adding the feature in the core dependency group and
that would mean pretty much no matter what container anyone was using
they'd end up sucking in the rpc register for the oauthpopup code. That
means the gadget feature code would get sucked in too when gadgets that
don't ex
gt; >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 fir
.sapu...@gmail.com]
>> Sent: Tuesday, August 21, 2012 7:17 PM
>> To: dev@shindig.apache.org
>> Subject: Re: Changing oauthpopup feature to introduce some container
>> cooperation...
>>
>> Dan,
>>
>> Since we are close to release 2.5 I would vote for option
>-Original Message-
>From: Henry Saputra [mailto:henry.sapu...@gmail.com]
>Sent: Tuesday, August 21, 2012 7:17 PM
>To: dev@shindig.apache.org
>Subject: Re: Changing oauthpopup feature to introduce some container
>cooperation...
>
>Dan,
>
>Since we are close t
>-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 th
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 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" 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,
Man, I've been having bad luck with my email addresses lately...
Trying again, please forgive any duplicates.
---
Yeah, for 2 I would be adding the feature in the core dependency group and
that would mean pretty much no matter what container anyone was using
they'd end up sucking in the rpc registe
Dan, can you elaborate on option 2? How would moving the oauthpopup
feature to core solve the upgrade problem? Is that simply where the
rpcregister would happen container-side?
On Aug 21, 2012 7:06 PM, "Ryan Baxter" wrote:
> I like option 1 but can understand why people would be upset, so optio
Dan,
Since we are close to release 2.5 I would vote for option 4.
We have other issues with Shindig to follow OS specs so unless it crucial
bug fix I think we should leave it for now.
- Henry
On Tuesday, August 21, 2012, Ryan Baxter wrote:
> I like option 1 but can understand why people would
I like option 1 but can understand why people would be upset, so option 4
may be your only option. Although I hope we could do option 1 post 2.5...
On Tue, Aug 21, 2012 at 11:17 AM, Dan Dumont wrote:
> I've been looking at having the oauth popup feature make some calls into
> the container over
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 s
18 matches
Mail list logo
