OAuth fields required?
I was trying to use the GadgetSpec class to retrieve some metadata fields from xml I passed into the constructor. However, this failed with ³/OAuth/Service/Request is required² on the ModulePrefs OAuth section. Are these fields really required? I thought they were optional and only used to override any settings that might be in the oauth repository. We¹ve implemented a database store for these values. We are thinking that it might actually be nice to use the GadgetSpec class to validate an xml file that is uploaded, but it would also be nice if it was validating against a schema instead of code to do the work. Has there been any thought given to this? Thanks, doug
Re: Handling missing gadget url
Ryan, Thanks for the explanation. I¹ve been on vacation, so sorry for not responding quicker. Should I open up an enhancement jira for this? doug On 10/29/12 8:47 PM, "Ryan Baxter" wrote: > So the gadget XML is not cached on the server, but the metadata request is > cached on the client? The NO_CACHE option looks like it is only used to > tell shindig to render the gadget in debug mode. It is also specifically > used for rendering gadgets not for caching in the container. The metadata > caching functionality in the common container is lacking. Not only is it > always cached, but the common container never purges the cache. It > wouldn't be hard to check for whether the container is in debug mode and > disable the caching. Unless we want to introduce a separate caching param > for the container as well... > > On Thu, Oct 25, 2012 at 9:57 AM, daviesd wrote: > >> > I have a scenario where a gadget is rendered from a known url, dropbox lets >> > say. If later on if I remove the gadget from dropbox and my container >> > tries >> > to re-render it I get the message >> > >> > Unable to retrieve spec for >> > https://dl.dropbox.com/u/x/gadgets/oauth2.xml. HTTP error 404 >> > >> > Which seems to come from AbstractSpecFactory.java within Shindig. >> > >> > However the call to holder.getGadgetInfo still returns the cached entry, so >> > there is no way for me to detect this scenario so that I can handle it >> > appropriately in my chrome elements (disable things). >> > >> > If the gadget url is missing on the very first render, then I get back a >> > error inside gadgetInfo that is passed to the navigateGadget callback. >> > >> > I¹m pretty sure I have caching turned off when I render the gadget. >> > >> > renderParams[osapi.container.RenderParam.NO_CACHE] = true; >> > >> > Any ideas on how to detect that the gadget xml spec has gone away on the >> > first scenario? >> > >> > Thanks, >> > doug >> > >
Handling missing gadget url
I have a scenario where a gadget is rendered from a known url, dropbox lets say. If later on if I remove the gadget from dropbox and my container tries to re-render it I get the message Unable to retrieve spec for https://dl.dropbox.com/u/x/gadgets/oauth2.xml. HTTP error 404 Which seems to come from AbstractSpecFactory.java within Shindig. However the call to holder.getGadgetInfo still returns the cached entry, so there is no way for me to detect this scenario so that I can handle it appropriately in my chrome elements (disable things). If the gadget url is missing on the very first render, then I get back a error inside gadgetInfo that is passed to the navigateGadget callback. I¹m pretty sure I have caching turned off when I render the gadget. renderParams[osapi.container.RenderParam.NO_CACHE] = true; Any ideas on how to detect that the gadget xml spec has gone away on the first scenario? Thanks, doug
Re: Gaget's requestNavigateTo and Containers navigateGadget
Here's what we do.
container.rpcRegister("requestNavigateTo", function
requestNavigateTo(rpcArgs, view, params) {
var site = rpcArgs[osapi.container.GadgetSite.RPC_ARG_KEY],
url = site.getActiveSiteHolder().getUrl(),
renderParams = {};
renderParams[osapi.container.RenderParam.VIEW] = view;
container.navigateGadget( site, url, params, renderParams );
});
Does that help?
doug
On 10/2/12 12:54 PM, "bauma...@us.ibm.com" wrote:
> I am trying to create a custom container based on Shindig and am a bit
> confused on the relationship between a gadget calling 'requestNavigateTo'
> and the container function 'navigateGadget'.
>
> I am trying to implement the rpc callback for requestNavigateTo as Shindig
> does not, and the only way I can find to render the gadget with a specific
> view is a call to Container.navigateGadget. The disconnect I have is that
> navigateGadget requires an url for the gadget to render but
> requestNavigateTo does not pass the url of the calling gadget. Is it
> intentional that the data passed to the rpc call from requestNavigateTo
> does not include the calling Gadget's url, or am I missing the reference
> somewhere in an object somewhere? Is there a different function in the
> container that I can call to render the view that uses the current url of
> a gadget site?
>
> Thank you,
>
> Brian Bauman
> IBM Software Group - Austin, TX
> Live Text Dev and Lotus Expeditor Release Engineer
> bauma...@us.ibm.com
> (512) 286-5271 (T/L 363-5271)
Re: Overriding Guice Modules
Thanks. That works! Appreciate the direction. doug On 9/4/12 10:42 AM, "Stanton Sievers" wrote: > Hi Doug, > > Does the Modules.override functionality in guice help at all? I'm > wondering if you can override the DefaulyGuiceModule with a module that > does you binding. > > -Stanton > On Sep 4, 2012 9:47 AM, "daviesd" wrote: > >> If I wanted to implement my own Authority implementation (replacing >> BasicAuthority) it appears that I would have to completely override the >> DefaultGuiceModule and just change one line to bind to my implementation. >> However, this means every time I upgrade artifacts I have to make sure the >> default implementation hasn¹t changed (new bindings, deleted bindings, >> renamed, etc.). Is this the intended behavior or am I missing something? >> We currently do this with the social apis, but of course those are split >> out >> into their own guice module and meant to be overriden. If I could at least >> extend DefaultGuiceModule and have it call my additional configuration >> that¹d be great, but I don¹t think you can unbind with guice (that I¹ve >> found). Ideas? >> >> Doug >>
Re: Overriding Guice Modules
Wow! I didn't know about this. Thanks for the info. Yes, this might just work. I'll let ya know. doug On 9/4/12 10:42 AM, "Stanton Sievers" wrote: > Hi Doug, > > Does the Modules.override functionality in guice help at all? I'm > wondering if you can override the DefaulyGuiceModule with a module that > does you binding. > > -Stanton > On Sep 4, 2012 9:47 AM, "daviesd" wrote: > >> If I wanted to implement my own Authority implementation (replacing >> BasicAuthority) it appears that I would have to completely override the >> DefaultGuiceModule and just change one line to bind to my implementation. >> However, this means every time I upgrade artifacts I have to make sure the >> default implementation hasn¹t changed (new bindings, deleted bindings, >> renamed, etc.). Is this the intended behavior or am I missing something? >> We currently do this with the social apis, but of course those are split >> out >> into their own guice module and meant to be overriden. If I could at least >> extend DefaultGuiceModule and have it call my additional configuration >> that¹d be great, but I don¹t think you can unbind with guice (that I¹ve >> found). Ideas? >> >> Doug >>
Overriding Guice Modules
If I wanted to implement my own Authority implementation (replacing BasicAuthority) it appears that I would have to completely override the DefaultGuiceModule and just change one line to bind to my implementation. However, this means every time I upgrade artifacts I have to make sure the default implementation hasn¹t changed (new bindings, deleted bindings, renamed, etc.). Is this the intended behavior or am I missing something? We currently do this with the social apis, but of course those are split out into their own guice module and meant to be overriden. If I could at least extend DefaultGuiceModule and have it call my additional configuration that¹d be great, but I don¹t think you can unbind with guice (that I¹ve found). Ideas? Doug
Re: Changing oauthpopup feature to introduce some container cooperation...
+1 On 8/23/12 9:23 AM, "Dan Dumont" 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 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. >> 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 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" 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? >>>>> >>>>> >>>>> >>> >> >>
Re: Changing oauthpopup feature to introduce some container cooperation...
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, 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?
Re: [RESULT] [VOTE] Release Apache Shindig version 2.5.0-beta3
Kind of. I just made it so the dns host used on the initial call was opened up from the shindig server. I still don't like that it uses the host from the initial request, but I guess it makes sense. I think eventually I will have to write my own Authority because I think this might muck with the oauth callback urls that are used if they aren't provided in the db (set to null). doug On 8/1/12 4:55 PM, "Henry Saputra" wrote: > Doug, > > Did you resolve the issue with rpc endpoint? > > - Henry > > On Wed, Aug 1, 2012 at 1:50 PM, daviesd wrote: >> Looks good. Running with it now. >> >> >> On 8/1/12 3:12 PM, "Ryan Baxter" wrote: >> >>> The release has been promoted to the central maven repo [1] and to the >>> distribution site [2]. There is now a 2.5.0-beta4 release in JIRA >>> that we can use for JIRAs moving forward. We will try to stay on >>> target and release 2.5.0-beta4 at the end of August. >>> >>> [1] https://repository.apache.org/ >>> [2] http://www.apache.org/dist/shindig/2.5.0-beta3/ >>> >>> -Ryan >>> >>> On Tue, Jul 31, 2012 at 8:21 PM, Ryan Baxter wrote: >>>> Hi, >>>> The vote has passed with the following result : >>>> >>>> +1 (binding): Stanton Sievers, Ryan Baxter, Henry Saptura >>>> +1 (non binding): Doug Davies >>>> >>>> I will promote the artifacts to the central repo. >>>> >>>> >>>> -Ryan >>>> >>>> >>>> On Tue, Jul 31, 2012 at 8:17 PM, Ryan Baxter wrote: >>>>> >>>>> +1 binding >>>>> >>>>> -Ryan >>>>> >>>>> >>>>> On Mon, Jul 30, 2012 at 9:03 AM, Stanton Sievers >>>>> wrote: >>>>>> >>>>>> +1, binding >>>>>> >>>>>> Tested things out in the sample container. Everything looks good. >>>>>> >>>>>> Thanks, >>>>>> -Stanton >>>>>> >>>>>> >>>>>> >>>>>> From: Ryan Baxter >>>>>> To: dev@shindig.apache.org, >>>>>> Date: 07/25/2012 22:54 >>>>>> Subject:[VOTE] Release Apache Shindig version 2.5.0-beta3 >>>>>> >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> We solved 19 issues: >>>>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQ >>>>>> ue >>>>>> ry=project+%3D+SHINDIG+AND+fixVersion+%3D+%272.5.0-beta3%27 >>>>>> >>>>>> >>>>>> Staging repo: >>>>>> https://repository.apache.org/content/repositories/orgapacheshindig-090/ >>>>>> >>>>>> Web site: >>>>>> http://shindig.apache.org/ >>>>>> >>>>>> Vote open for 72 hours. >>>>>> >>>>>> [ ] +1 >>>>>> [ ] +0 >>>>>> [ ] -1 >>>>>> >>>>>> >>>>>> -Ryan >>>>>> >>>>>> >>>>> >>> >> >> >
Re: [RESULT] [VOTE] Release Apache Shindig version 2.5.0-beta3
Looks good. Running with it now. On 8/1/12 3:12 PM, "Ryan Baxter" wrote: > The release has been promoted to the central maven repo [1] and to the > distribution site [2]. There is now a 2.5.0-beta4 release in JIRA > that we can use for JIRAs moving forward. We will try to stay on > target and release 2.5.0-beta4 at the end of August. > > [1] https://repository.apache.org/ > [2] http://www.apache.org/dist/shindig/2.5.0-beta3/ > > -Ryan > > On Tue, Jul 31, 2012 at 8:21 PM, Ryan Baxter wrote: >> Hi, >> The vote has passed with the following result : >> >> +1 (binding): Stanton Sievers, Ryan Baxter, Henry Saptura >> +1 (non binding): Doug Davies >> >> I will promote the artifacts to the central repo. >> >> >> -Ryan >> >> >> On Tue, Jul 31, 2012 at 8:17 PM, Ryan Baxter wrote: >>> >>> +1 binding >>> >>> -Ryan >>> >>> >>> On Mon, Jul 30, 2012 at 9:03 AM, Stanton Sievers >>> wrote: +1, binding Tested things out in the sample container. Everything looks good. Thanks, -Stanton From: Ryan Baxter To: dev@shindig.apache.org, Date: 07/25/2012 22:54 Subject:[VOTE] Release Apache Shindig version 2.5.0-beta3 Hi, We solved 19 issues: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQue ry=project+%3D+SHINDIG+AND+fixVersion+%3D+%272.5.0-beta3%27 Staging repo: https://repository.apache.org/content/repositories/orgapacheshindig-090/ Web site: http://shindig.apache.org/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -Ryan >>> >
Re: Shindig host (help -- kind of urgent)
They don't live on different hosts, they are just gotten there by different dns. For example the javascript request looks like: https://prefix.shindighost.com/gadgets/js/rpc.js?nocache=1&c=1&container=def ault However the server shouldn't go through prefix.shindighost.com. I really want it to go to shindighost.com. Sounds like I don't want it to use the "host" header but instead set shindig.host appropriately. Especially since the authority is used by other things like the oauth callbacks. doug On 7/31/12 12:57 PM, "Henry Saputra" wrote: > Looks like the rpc call to system.listMethods is called in > RenderingGadgetRewriter and ConfigInjectionProcessor to execute the > gadgets.config.init > > For both scenario looks t will try to call itself using the request > "host" header. > > Doug, so in your setup the js serving endpoint live in different host > than the rpc endpoints? > > - Henry > > On Tue, Jul 31, 2012 at 8:03 AM, daviesd wrote: >> I just recently noticed a behavior with the rpc interface that I have >> discovered in the 11th hour and we are ready to rollout, so any input asap >> is appreciated. >> >> Shindig at some point makes an rpc call back to itself for listMethods. I >> thought this use to happen upon startup, but I might be wrong. What appears >> to be happening is that it does this on the first request for the shindig >> javascript. And if you don¹t have a shindig host configured it appears to >> use the dns/host name from the request. >> >> Unfortunately in my environment that initial javascript goes to a different >> dns/host name than what I want my shindig server to use. I still don¹t >> understand why the shindig call doesn¹t use localhost (or just call >> internally to itself). >> >> Is just configuring shindig.host going to be enough to get around this >> problem? >> >> Thanks, >> doug >
Shindig host (help -- kind of urgent)
I just recently noticed a behavior with the rpc interface that I have discovered in the 11th hour and we are ready to rollout, so any input asap is appreciated. Shindig at some point makes an rpc call back to itself for listMethods. I thought this use to happen upon startup, but I might be wrong. What appears to be happening is that it does this on the first request for the shindig javascript. And if you don¹t have a shindig host configured it appears to use the dns/host name from the request. Unfortunately in my environment that initial javascript goes to a different dns/host name than what I want my shindig server to use. I still don¹t understand why the shindig call doesn¹t use localhost (or just call internally to itself). Is just configuring shindig.host going to be enough to get around this problem? Thanks, doug
Re: [VOTE] Release Apache Shindig version 2.5.0-beta3
+1 (non-binding) The two issue I needed (SHINDIG-1799 & SHINDIG-1812) are working for me. BTW... Not sure why 1799 doesn't show up in your fixed list, but I show it as being fixed after beta2. doug On 7/25/12 10:56 PM, "Ryan Baxter" wrote: > Hi, > > We solved 19 issues: > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery= > project+%3D+SHINDIG+AND+fixVersion+%3D+%272.5.0-beta3%27 > > Staging repo: > https://repository.apache.org/content/repositories/orgapacheshindig-090/ > > Web site: > http://shindig.apache.org/ > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > > -Ryan >
Re: Beta3
Private list? I knew I was missing a party somewhere! :) Great. I looked forward to beta3. I think monthly betas are much better. That last one was a lot to bite off at once. Can you elaborate on the blocking issue? doug On 7/20/12 6:44 PM, "Ryan Baxter" wrote: > Hi Doug, > > There has been an issue identified on the private list that is > blocking the release. The fix should be checked in early next week > and I will kick off a beta 3 RC right after that. > > -Ryan > > On Fri, Jul 20, 2012 at 2:57 PM, daviesd wrote: >> Ideas when beta3 is coming? I know there was talk about it earlier in the >> month. I¹d love to get a beta3 before too many more changes go in, since >> I¹m really only interested in 2 things that got fixed post beta2, and I¹d >> hate to have to do the amount of work I had to do to get from beta1 to >> beta2. >> >> Thanks, >> Doug >> >
Beta3
Ideas when beta3 is coming? I know there was talk about it earlier in the month. I¹d love to get a beta3 before too many more changes go in, since I¹m really only interested in 2 things that got fixed post beta2, and I¹d hate to have to do the amount of work I had to do to get from beta1 to beta2. Thanks, Doug
iGoogle
Anyone have any opinion what the shutdown of iGoogle means for Google¹s support of OpenSocial? I¹m assuming (but don¹t know for sure) that Google+, etc. use opensocial (or at least google gadgets)? Doesn¹t this just mean that Google+ might become the new home for installing gadgets? I know the Googlers probably can¹t comment on this. Just wondering if this has any bearing on opensocial. doug
Re: Horoscope gadget and the common container
Ryan,
Thanks for getting beta2 out there. I've integrated it into our project and
it looks good. In the meantime I'm just patching our files to get around
the makeRequest issue. July 6th should be good for us moving to beta3.
Thanks for getting us on a timely schedule.
doug
On 6/26/12 8:57 AM, "Ryan J Baxter" wrote:
> Doug I released 2.5.0-beta2 last night so recutting beta2 is not an option
> now :)
>
> Since I want to try to stick to the monthly release process we agreed upon
> I was planning on cutting beta3 RC1 early next week with a targeted
> release date of 7/6. Will that work for you?
>
> -Ryan
>
>
>
>
> From: daviesd
> To: ,
> Date: 06/25/2012 06:12 PM
> Subject:Re: Horoscope gadget and the common container
>
>
>
> Ok, I will retest with your patch in the morning.
>
> Ryan... You're not even gonna like my next question but we are releasing
> our
> stuff in 2 weeks and really need to be on a stable beta. If we can't get
> another beta (or recut beta2) then I'll probably need to figure out how to
> apply this fix to our container that will use the beta2 artifacts. Ideas
> on
> how to best approach this?
>
> Thanks,
> doug
>
>
> On 6/25/12 6:05 PM, "Stanton Sievers" wrote:
>
>> Hi Doug,
>>
>> It must be a difference in the way that FF sets the header compared to
>> WebKit. FF's XHR implementation must take "null" and set the header
> value
>> to be empty which we treat as null on the server. WebKit on the other
>> hand is setting the header value to the value "null", which we then
> treat
>> as a String on the server.
>>
>> https://reviews.apache.org/r/5568/
>> https://issues.apache.org/jira/browse/SHINDIG-1812
>>
>> Thanks,
>> -Stanton
>>
>>
>>
>> From: daviesd
>> To: ,
>> Date: 06/25/2012 17:18
>> Subject:Re: Horoscope gadget and the common container
>>
>>
>>
>> Thanks Ryan. I had that set on my container but not on my shindig
> trunk.
>>
>> So I was able to reproduce the problem now with shindig trunk. If you
> try
>> rendering the horoscope gadget under firefox and type in a date and hit
>> submit it will work (the makeRequest fetches a horoscope). Under chrome
>> or
>> safari it will blow up.
>>
>> Here's what I think it going on.
>>
>> In io.js this code
>>
>> var opt_headers = {
>> 'X-Shindig-ST' : shindig.auth.getSecurityToken()
>> };
>>
>> behaves differently. Even though I see both browsers set it as follows:
>>
>> {"X-Shindig-ST":null}
>>
>> later on in UrlParameterAuthenticationHandler it's set to the STRING
>> "null"
>> (not the value null) for webkit browsers.
>>
>>// no token yet, see if it was attached as a header
>> if (StringUtils.isEmpty(token)) {
>> String t = request.getHeader( "X-Shindig-ST" );
>> if (StringUtils.isNotBlank(t)) {
>> token = t;
>> }
>> }
>>
>> This blows up during decryption:
>>
>> Maybe Stanton can comment since he made the X-Shindig-ST changes.
>>
>> doug
>>
>> On 6/25/12 4:36 PM, "Ryan J Baxter" wrote:
>>
>>> Doug add shindig.urlgen.use-templates-default=false to your
>>> shindig.properties file and try again.
>>>
>>> -Ryan
>>>
>>>
>>>
>>>
>>> From: daviesd
>>> To: ,
>>> Date: 06/25/2012 03:36 PM
>>> Subject:Re: Horoscope gadget and the common container
>>>
>>>
>>>
>>> Ya, I went back and tested on beta1 and it doesn't work there either,
> so
>>> perhaps I won't worry about it.
>>>
>>>
>>> On 6/25/12 3:23 PM, "daviesd" wrote:
>>>
>>>> Ya, it's complaining about the %up_uid% parameter.
>>>>
>>>>
>>>
>>
> http://feeds.tarot.com/f/ws/dh/igoogledh/locale/en/timezone/-4/uid/%up_uid%?pa
>
>>
>>>
>>>> rtner=igoogle&key=a9a51c94bbb165f9&type=xml&time=1340651940753
>>>>
>>>> Is common container have an implementation of userprefs? Perhaps this
>>> never
>>>> worked.
>>>>
>>>> Doug
>>>>
>>>> On 6/25/12 2:47 PM, "Dan Dumont" wrote:
>>>&
Re: Horoscope gadget and the common container
Ok, I will retest with your patch in the morning.
Ryan... You're not even gonna like my next question but we are releasing our
stuff in 2 weeks and really need to be on a stable beta. If we can't get
another beta (or recut beta2) then I'll probably need to figure out how to
apply this fix to our container that will use the beta2 artifacts. Ideas on
how to best approach this?
Thanks,
doug
On 6/25/12 6:05 PM, "Stanton Sievers" wrote:
> Hi Doug,
>
> It must be a difference in the way that FF sets the header compared to
> WebKit. FF's XHR implementation must take "null" and set the header value
> to be empty which we treat as null on the server. WebKit on the other
> hand is setting the header value to the value "null", which we then treat
> as a String on the server.
>
> https://reviews.apache.org/r/5568/
> https://issues.apache.org/jira/browse/SHINDIG-1812
>
> Thanks,
> -Stanton
>
>
>
> From: daviesd
> To: ,
> Date: 06/25/2012 17:18
> Subject:Re: Horoscope gadget and the common container
>
>
>
> Thanks Ryan. I had that set on my container but not on my shindig trunk.
>
> So I was able to reproduce the problem now with shindig trunk. If you try
> rendering the horoscope gadget under firefox and type in a date and hit
> submit it will work (the makeRequest fetches a horoscope). Under chrome
> or
> safari it will blow up.
>
> Here's what I think it going on.
>
> In io.js this code
>
> var opt_headers = {
> 'X-Shindig-ST' : shindig.auth.getSecurityToken()
> };
>
> behaves differently. Even though I see both browsers set it as follows:
>
> {"X-Shindig-ST":null}
>
> later on in UrlParameterAuthenticationHandler it's set to the STRING
> "null"
> (not the value null) for webkit browsers.
>
>// no token yet, see if it was attached as a header
> if (StringUtils.isEmpty(token)) {
> String t = request.getHeader( "X-Shindig-ST" );
> if (StringUtils.isNotBlank(t)) {
> token = t;
> }
> }
>
> This blows up during decryption:
>
> Maybe Stanton can comment since he made the X-Shindig-ST changes.
>
> doug
>
> On 6/25/12 4:36 PM, "Ryan J Baxter" wrote:
>
>> Doug add shindig.urlgen.use-templates-default=false to your
>> shindig.properties file and try again.
>>
>> -Ryan
>>
>>
>>
>>
>> From: daviesd
>> To: ,
>> Date: 06/25/2012 03:36 PM
>> Subject:Re: Horoscope gadget and the common container
>>
>>
>>
>> Ya, I went back and tested on beta1 and it doesn't work there either, so
>> perhaps I won't worry about it.
>>
>>
>> On 6/25/12 3:23 PM, "daviesd" wrote:
>>
>>> Ya, it's complaining about the %up_uid% parameter.
>>>
>>>
>>
> http://feeds.tarot.com/f/ws/dh/igoogledh/locale/en/timezone/-4/uid/%up_uid%?pa
>
>>
>>> rtner=igoogle&key=a9a51c94bbb165f9&type=xml&time=1340651940753
>>>
>>> Is common container have an implementation of userprefs? Perhaps this
>> never
>>> worked.
>>>
>>> Doug
>>>
>>> On 6/25/12 2:47 PM, "Dan Dumont" wrote:
>>>
>>>> Are you able to set a debug point in the makeRequest servlet to see
>> where
>>>> the exception is being thrown? Do you get any server stack traces?
>>>>
>>>>
>>>>
>>>> From: daviesd
>>>> To: shindig ,
>>>> Date: 06/25/2012 02:37 PM
>>>> Subject:Horoscope gadget and the common container
>>>>
>>>>
>>>>
>>>> I noticed that the horoscope gadget is not working in the common
>> container
>>>> anymore. I see the following error in the javascript console.
>>>>
>>>> "NetworkError: 400 Invalid url parameter -
>>>>
>>
> http://localhost:8080/gadgets/makeRequest?url=http%3A%2F%2Fapi.tarot.com%2Fa
>
>>
>>>>
>>>>
>>
> pi%2Fastrosync%2Ftimezone%2F-4%2Fdate%2F2012-06-25%2Ftime%2F1421%2Ftype%2Fxm
>>>>
>>
> l%3Fpartner%3Digoogle%26key%3Da9a51c94bbb165f9%26uid%3D%25up_uid%25&httpMeth
>>>>
>>
> od=GET&headers=&postData=&authz=&st=&contentType=DOM&numEntries=3&getSummari
>>>>
>>
> es=false&signOwner=true&signViewer=true&gadget=http%3A%
Re: Horoscope gadget and the common container
Thanks Ryan. I had that set on my container but not on my shindig trunk.
So I was able to reproduce the problem now with shindig trunk. If you try
rendering the horoscope gadget under firefox and type in a date and hit
submit it will work (the makeRequest fetches a horoscope). Under chrome or
safari it will blow up.
Here's what I think it going on.
In io.js this code
var opt_headers = {
'X-Shindig-ST' : shindig.auth.getSecurityToken()
};
behaves differently. Even though I see both browsers set it as follows:
{"X-Shindig-ST":null}
later on in UrlParameterAuthenticationHandler it's set to the STRING "null"
(not the value null) for webkit browsers.
// no token yet, see if it was attached as a header
if (StringUtils.isEmpty(token)) {
String t = request.getHeader( "X-Shindig-ST" );
if (StringUtils.isNotBlank(t)) {
token = t;
}
}
This blows up during decryption:
Maybe Stanton can comment since he made the X-Shindig-ST changes.
doug
On 6/25/12 4:36 PM, "Ryan J Baxter" wrote:
> Doug add shindig.urlgen.use-templates-default=false to your
> shindig.properties file and try again.
>
> -Ryan
>
>
>
>
> From: daviesd
> To: ,
> Date: 06/25/2012 03:36 PM
> Subject:Re: Horoscope gadget and the common container
>
>
>
> Ya, I went back and tested on beta1 and it doesn't work there either, so
> perhaps I won't worry about it.
>
>
> On 6/25/12 3:23 PM, "daviesd" wrote:
>
>> Ya, it's complaining about the %up_uid% parameter.
>>
>>
> http://feeds.tarot.com/f/ws/dh/igoogledh/locale/en/timezone/-4/uid/%up_uid%?pa
>
>> rtner=igoogle&key=a9a51c94bbb165f9&type=xml&time=1340651940753
>>
>> Is common container have an implementation of userprefs? Perhaps this
> never
>> worked.
>>
>> Doug
>>
>> On 6/25/12 2:47 PM, "Dan Dumont" wrote:
>>
>>> Are you able to set a debug point in the makeRequest servlet to see
> where
>>> the exception is being thrown? Do you get any server stack traces?
>>>
>>>
>>>
>>> From: daviesd
>>> To: shindig ,
>>> Date: 06/25/2012 02:37 PM
>>> Subject:Horoscope gadget and the common container
>>>
>>>
>>>
>>> I noticed that the horoscope gadget is not working in the common
> container
>>> anymore. I see the following error in the javascript console.
>>>
>>> "NetworkError: 400 Invalid url parameter -
>>>
> http://localhost:8080/gadgets/makeRequest?url=http%3A%2F%2Fapi.tarot.com%2Fa
>
>>>
>>>
> pi%2Fastrosync%2Ftimezone%2F-4%2Fdate%2F2012-06-25%2Ftime%2F1421%2Ftype%2Fxm
>>>
> l%3Fpartner%3Digoogle%26key%3Da9a51c94bbb165f9%26uid%3D%25up_uid%25&httpMeth
>>>
> od=GET&headers=&postData=&authz=&st=&contentType=DOM&numEntries=3&getSummari
>>>
> es=false&signOwner=true&signViewer=true&gadget=http%3A%2F%2Fwww.google.com%2
>>>
> Fig%2Fmodules%2Fhoroscope.xml&container=default&bypassSpecCache=1&getFullHea
>>> ders=false&refresh=1"
>>>
>>> Is this potentially because opensocial-0.8 and older apis have been
>>> deprecated? I can¹t remember if this gadget was suppose to work anyway
>>> since I¹m not sure the commoncontainer implements userprefs.
>>>
>>> The reason I ask is because in our container (using shindig trunk
>>> artifacts)
>>> it does work. We¹ve implemented userprefs. However, it only works in
>>> non-webkit browsers (firefox). It blows up on the server-side when
> called
>>> from Safari/Chrome.
>>>
>>> org.apache.shindig.auth.SecurityTokenException: Invalid security token
>>> null
>>> at
>>>
> org.apache.shindig.auth.BlobCrypterSecurityTokenCodec.createToken(BlobCrypte
>>> rSecurityTokenCodec.java:140)
>>> at
>>>
> org.oclc.platform.opensocial.core.auth.PlatformDefaultSecurityTokenCodec.cre
>>> ateToken(PlatformDefaultSecurityTokenCodec.java:54)
>>> at
>>>
> org.apache.shindig.auth.UrlParameterAuthenticationHandler.getSecurityTokenFr
>>> omRequest(UrlParameterAuthenticationHandler.java:63)
>>> at
>>>
> org.apache.shindig.auth.AuthenticationServletFilter.doFilter(AuthenticationS
>>> ervletFilter.java:92)
>>>
>>> I¹d like to test this from common container without my implementations
>>> interfering, but as I said it just doesn¹t render there.
>>>
>>> Doug
>>>
>>>
>
>
>
Re: Horoscope gadget and the common container
Ya, I went back and tested on beta1 and it doesn't work there either, so perhaps I won't worry about it. On 6/25/12 3:23 PM, "daviesd" wrote: > Ya, it's complaining about the %up_uid% parameter. > > http://feeds.tarot.com/f/ws/dh/igoogledh/locale/en/timezone/-4/uid/%up_uid%?pa > rtner=igoogle&key=a9a51c94bbb165f9&type=xml&time=1340651940753 > > Is common container have an implementation of userprefs? Perhaps this never > worked. > > Doug > > On 6/25/12 2:47 PM, "Dan Dumont" wrote: > >> Are you able to set a debug point in the makeRequest servlet to see where >> the exception is being thrown? Do you get any server stack traces? >> >> >> >> From: daviesd >> To: shindig , >> Date: 06/25/2012 02:37 PM >> Subject:Horoscope gadget and the common container >> >> >> >> I noticed that the horoscope gadget is not working in the common container >> anymore. I see the following error in the javascript console. >> >> "NetworkError: 400 Invalid url parameter - >> http://localhost:8080/gadgets/makeRequest?url=http%3A%2F%2Fapi.tarot.com%2Fa >> >> pi%2Fastrosync%2Ftimezone%2F-4%2Fdate%2F2012-06-25%2Ftime%2F1421%2Ftype%2Fxm >> l%3Fpartner%3Digoogle%26key%3Da9a51c94bbb165f9%26uid%3D%25up_uid%25&httpMeth >> od=GET&headers=&postData=&authz=&st=&contentType=DOM&numEntries=3&getSummari >> es=false&signOwner=true&signViewer=true&gadget=http%3A%2F%2Fwww.google.com%2 >> Fig%2Fmodules%2Fhoroscope.xml&container=default&bypassSpecCache=1&getFullHea >> ders=false&refresh=1" >> >> Is this potentially because opensocial-0.8 and older apis have been >> deprecated? I can¹t remember if this gadget was suppose to work anyway >> since I¹m not sure the commoncontainer implements userprefs. >> >> The reason I ask is because in our container (using shindig trunk >> artifacts) >> it does work. We¹ve implemented userprefs. However, it only works in >> non-webkit browsers (firefox). It blows up on the server-side when called >> from Safari/Chrome. >> >> org.apache.shindig.auth.SecurityTokenException: Invalid security token >> null >> at >> org.apache.shindig.auth.BlobCrypterSecurityTokenCodec.createToken(BlobCrypte >> rSecurityTokenCodec.java:140) >> at >> org.oclc.platform.opensocial.core.auth.PlatformDefaultSecurityTokenCodec.cre >> ateToken(PlatformDefaultSecurityTokenCodec.java:54) >> at >> org.apache.shindig.auth.UrlParameterAuthenticationHandler.getSecurityTokenFr >> omRequest(UrlParameterAuthenticationHandler.java:63) >> at >> org.apache.shindig.auth.AuthenticationServletFilter.doFilter(AuthenticationS >> ervletFilter.java:92) >> >> I¹d like to test this from common container without my implementations >> interfering, but as I said it just doesn¹t render there. >> >> Doug >> >>
Re: Horoscope gadget and the common container
Ya, it's complaining about the %up_uid% parameter. http://feeds.tarot.com/f/ws/dh/igoogledh/locale/en/timezone/-4/uid/%up_uid%? partner=igoogle&key=a9a51c94bbb165f9&type=xml&time=1340651940753 Is common container have an implementation of userprefs? Perhaps this never worked. Doug On 6/25/12 2:47 PM, "Dan Dumont" wrote: > Are you able to set a debug point in the makeRequest servlet to see where > the exception is being thrown? Do you get any server stack traces? > > > > From: daviesd > To: shindig , > Date: 06/25/2012 02:37 PM > Subject:Horoscope gadget and the common container > > > > I noticed that the horoscope gadget is not working in the common container > anymore. I see the following error in the javascript console. > > "NetworkError: 400 Invalid url parameter - > http://localhost:8080/gadgets/makeRequest?url=http%3A%2F%2Fapi.tarot.com%2Fa > > pi%2Fastrosync%2Ftimezone%2F-4%2Fdate%2F2012-06-25%2Ftime%2F1421%2Ftype%2Fxm > l%3Fpartner%3Digoogle%26key%3Da9a51c94bbb165f9%26uid%3D%25up_uid%25&httpMeth > od=GET&headers=&postData=&authz=&st=&contentType=DOM&numEntries=3&getSummari > es=false&signOwner=true&signViewer=true&gadget=http%3A%2F%2Fwww.google.com%2 > Fig%2Fmodules%2Fhoroscope.xml&container=default&bypassSpecCache=1&getFullHea > ders=false&refresh=1" > > Is this potentially because opensocial-0.8 and older apis have been > deprecated? I can¹t remember if this gadget was suppose to work anyway > since I¹m not sure the commoncontainer implements userprefs. > > The reason I ask is because in our container (using shindig trunk > artifacts) > it does work. We¹ve implemented userprefs. However, it only works in > non-webkit browsers (firefox). It blows up on the server-side when called > from Safari/Chrome. > > org.apache.shindig.auth.SecurityTokenException: Invalid security token > null > at > org.apache.shindig.auth.BlobCrypterSecurityTokenCodec.createToken(BlobCrypte > rSecurityTokenCodec.java:140) > at > org.oclc.platform.opensocial.core.auth.PlatformDefaultSecurityTokenCodec.cre > ateToken(PlatformDefaultSecurityTokenCodec.java:54) > at > org.apache.shindig.auth.UrlParameterAuthenticationHandler.getSecurityTokenFr > omRequest(UrlParameterAuthenticationHandler.java:63) > at > org.apache.shindig.auth.AuthenticationServletFilter.doFilter(AuthenticationS > ervletFilter.java:92) > > I¹d like to test this from common container without my implementations > interfering, but as I said it just doesn¹t render there. > > Doug > >
Horoscope gadget and the common container
I noticed that the horoscope gadget is not working in the common container anymore. I see the following error in the javascript console. "NetworkError: 400 Invalid url parameter - http://localhost:8080/gadgets/makeRequest?url=http%3A%2F%2Fapi.tarot.com%2Fa pi%2Fastrosync%2Ftimezone%2F-4%2Fdate%2F2012-06-25%2Ftime%2F1421%2Ftype%2Fxm l%3Fpartner%3Digoogle%26key%3Da9a51c94bbb165f9%26uid%3D%25up_uid%25&httpMeth od=GET&headers=&postData=&authz=&st=&contentType=DOM&numEntries=3&getSummari es=false&signOwner=true&signViewer=true&gadget=http%3A%2F%2Fwww.google.com%2 Fig%2Fmodules%2Fhoroscope.xml&container=default&bypassSpecCache=1&getFullHea ders=false&refresh=1" Is this potentially because opensocial-0.8 and older apis have been deprecated? I can¹t remember if this gadget was suppose to work anyway since I¹m not sure the commoncontainer implements userprefs. The reason I ask is because in our container (using shindig trunk artifacts) it does work. We¹ve implemented userprefs. However, it only works in non-webkit browsers (firefox). It blows up on the server-side when called from Safari/Chrome. org.apache.shindig.auth.SecurityTokenException: Invalid security token null at org.apache.shindig.auth.BlobCrypterSecurityTokenCodec.createToken(BlobCrypte rSecurityTokenCodec.java:140) at org.oclc.platform.opensocial.core.auth.PlatformDefaultSecurityTokenCodec.cre ateToken(PlatformDefaultSecurityTokenCodec.java:54) at org.apache.shindig.auth.UrlParameterAuthenticationHandler.getSecurityTokenFr omRequest(UrlParameterAuthenticationHandler.java:63) at org.apache.shindig.auth.AuthenticationServletFilter.doFilter(AuthenticationS ervletFilter.java:92) I¹d like to test this from common container without my implementations interfering, but as I said it just doesn¹t render there. Doug
Re: Adding additional APIs to Shindig
Adam, So I suppose sometime in the future this would be something shindig might expose? (even though it's not in the spec) I guess rather than boxing myself in, I'm just wondering if the shindig project did expose an api for this would it do it like current apis and provide a REST and RPC interface or perhaps shindig itself would just get an admin console ui? I'm still leaning towards just using security tokens and the REST endpoint, realizing that this also exposes an rpc endpoint that I don't really want or need. But I don't know if this is really the intent for server to server communication, even though the spec suggests it. http://shindig.apache.org/overview.html Apache Shindig implements several OpenSocial APIs: OpenSocial REST: for server to server communication OpenSocial JSON-RPC: for gadget to server communication Javascript: for gadgets Having to generate a security token to make this request isn't feeling quite right. doug On 6/21/12 3:52 PM, "A Clarke" wrote: > Generally speaking there was nothing done to address the management of > gadget bindings and clients externally. > > >
Re: Adding additional APIs to Shindig
Just to clarify where my thinking was headed. I need to provide an oauth client management api for a sandbox ui to use. This ui is not in the same webapp/host as shindig. In fact it's a completely separate environment that supports uploading of a gadget, collecting oauth client credentials, binding those credentials to the gadget, and rendering the gadget. I don't necessarily want the container javascript making the calls. It would most like be server to server. So I was leaning towards just plugging into the current rest/rpc handler and either securing this client management api via a security token or oauth2 (assuming I can do server to server with that). Or the other option is to just create an entirely different endpoint with a plain old servlet on the shindig side and handle the security using a shared secret. I guess I was just wondering if it's better to use the framework provided or homebrew this admin api myself. doug On 6/19/12 2:38 PM, "daviesd" wrote: > Thanks Stanton. So it sounds like you were saying to roll my own on this and > not try to leverage off of any existing shindig handlers? I certainly agree > on the security aspect. This would all take place over ssl. > > doug > > > On 6/18/12 5:26 PM, "Stanton Sievers" wrote: > >> Hi Doug, >> >> The largest challenge that I can see with doing what you're trying would >> be to secure that endpoint. Someone being able to add their own client >> could potentially be bad. From my viewpoint, if this is server to server, >> you would want to sign the request with Server 1's private key and encrypt >> with Server 2's public key. Server 2 would decrypt with their private key >> and verify the sender with Server 1's public key before adding the client. >> That would keep any old Joe from calling that endpoint and adding clients >> to your system. You would certainly want the client_secret to not be >> plaintext on the wire. That's my first thought, but I'm no security >> expert. :) >> >> Maybe I'm missing the point altogether... >> >> Thanks, >> -Stanton >> >> >> >> From: daviesd >> To: shindig , >> Date: 06/18/2012 16:28 >> Subject:Adding additional APIs to Shindig >> >> >> >> I have an API I want to add to our custom shindig server that doesn¹t fit >> any current opensocial specs (appdata, people, etc.). The API would allow >> our gadget sandbox webapp to create the oauth2 client and oauth2 gadget >> binding entries (server to server). >> >> So something like >> >> POST /opensocial/rest/oauth2client [client_id, client_secret, >> provider_name, >> application url] >> >> This would allow our sandbox gadget writers to enable oauth2 bindings >> without a third party having to be involved. >> >> My question is, what is the best way to expose such an API? Should I just >> expose it like all the other REST endpoints (and also via RPC) or should I >> just create a servlet with my own authentication scheme (perhaps just >> basic >> authentication)? If I use the existing framework should I use security >> tokens or should I use oauth2? >> >> I¹d be interested in hearing other viewpoints by people who have extended >> shindig with their own APIs. >> >> Thanks, >> Doug >> >>
Re: Adding additional APIs to Shindig
Thanks Stanton. So it sounds like you were saying to roll my own on this and not try to leverage off of any existing shindig handlers? I certainly agree on the security aspect. This would all take place over ssl. doug On 6/18/12 5:26 PM, "Stanton Sievers" wrote: > Hi Doug, > > The largest challenge that I can see with doing what you're trying would > be to secure that endpoint. Someone being able to add their own client > could potentially be bad. From my viewpoint, if this is server to server, > you would want to sign the request with Server 1's private key and encrypt > with Server 2's public key. Server 2 would decrypt with their private key > and verify the sender with Server 1's public key before adding the client. > That would keep any old Joe from calling that endpoint and adding clients > to your system. You would certainly want the client_secret to not be > plaintext on the wire. That's my first thought, but I'm no security > expert. :) > > Maybe I'm missing the point altogether... > > Thanks, > -Stanton > > > > From: daviesd > To: shindig , > Date: 06/18/2012 16:28 > Subject:Adding additional APIs to Shindig > > > > I have an API I want to add to our custom shindig server that doesn¹t fit > any current opensocial specs (appdata, people, etc.). The API would allow > our gadget sandbox webapp to create the oauth2 client and oauth2 gadget > binding entries (server to server). > > So something like > > POST /opensocial/rest/oauth2client [client_id, client_secret, > provider_name, > application url] > > This would allow our sandbox gadget writers to enable oauth2 bindings > without a third party having to be involved. > > My question is, what is the best way to expose such an API? Should I just > expose it like all the other REST endpoints (and also via RPC) or should I > just create a servlet with my own authentication scheme (perhaps just > basic > authentication)? If I use the existing framework should I use security > tokens or should I use oauth2? > > I¹d be interested in hearing other viewpoints by people who have extended > shindig with their own APIs. > > Thanks, > Doug > >
Adding additional APIs to Shindig
I have an API I want to add to our custom shindig server that doesn¹t fit any current opensocial specs (appdata, people, etc.). The API would allow our gadget sandbox webapp to create the oauth2 client and oauth2 gadget binding entries (server to server). So something like POST /opensocial/rest/oauth2client [client_id, client_secret, provider_name, application url] This would allow our sandbox gadget writers to enable oauth2 bindings without a third party having to be involved. My question is, what is the best way to expose such an API? Should I just expose it like all the other REST endpoints (and also via RPC) or should I just create a servlet with my own authentication scheme (perhaps just basic authentication)? If I use the existing framework should I use security tokens or should I use oauth2? I¹d be interested in hearing other viewpoints by people who have extended shindig with their own APIs. Thanks, Doug
Re: Pass token on listMethods to enable allowUnauthenticated=false (issue 6306074)
Guys, I apologize for the confusion. Ok, tested in my container. There needs to be one more fix. The container needs to be passed into retrieveServices and used instead of default. We define our own container in addition to default. Not sure why it doesn¹t find default, but it was throwing an exception until I passed our container name (oclc) through. Does this sound like a reasonable fix? Thanks, doug
Re: Pass token on listMethods to enable allowUnauthenticated=false (issue 6306074)
I am still having issues. I rebuilt everything with secure tokens enabled, but skipped tests so that the build would complete. Now the listMethods call succeeds, but then the metadata call fails with org.apache.shindig.auth.SecurityTokenException: Invalid security token john.doe:john.doe:appid:cont:url:0:default. This is with the 2 file patch you sent and shindig.properties allowUnauthenticated=false and secure tokens set in container.js. I am hitting the commoncontainer and trying to render horoscope. I'm off for the rest of the day. I'll check back on things on Monday. Doug
Re: Pass token on listMethods to enable allowUnauthenticated=false (issue 6306074)
Ya, I tried this with shindig trunk (and not my stuff). If you set
shindig.allowUnauthenticated=false
In shindig.properties and
"gadgets.securityTokenType" : "secure",
"gadgets.securityTokenKey" : "NotGonnaShowYouMyKey=",
In container.js
It blows up. I think this change needs to be reworked. You cannot encrypt
an Anonymous token. You probably were just setting allowUnauthenticated but
never really telling your container to use encrypted tokens.
The way I solved this was in AnonymousAuthenticationHandler.
public SecurityToken getSecurityTokenFromRequest(final
HttpServletRequest request) {
String uri = request.getRequestURI();
String method = request.getParameter("method");
if (allowUnauthenticated || (uri.endsWith("/rpc") && method != null
&& method.equals("system.listMethods"))) {
return new AnonymousSecurityToken();
}
return null;
}
Thanks,
doug
On 6/14/12 12:29 PM, "daviesd" wrote:
> I'm a little bit confused on this. I'm trying it and I'm getting an exception
> (it could be because I provide my own BlobCrypterSecurityTokenCodec and maybe
> I have some work to do here).
>
> When DefaultServiceFetcher creates an AnonymousSecurityToken and then calls
> encodeToken, won't that throw an exception because encodeToken doesn't support
> AnonymousSecurityTokens?
>
> doug
>
>
> On 6/13/12 1:50 PM, "btlil...@gmail.com" wrote:
>
>> Updated patch to use Anonymous Security Token
>>
>> http://codereview.appspot.com/6306074/
>>
Re: Pass token on listMethods to enable allowUnauthenticated=false (issue 6306074)
I'm a little bit confused on this. I'm trying it and I'm getting an exception (it could be because I provide my own BlobCrypterSecurityTokenCodec and maybe I have some work to do here). When DefaultServiceFetcher creates an AnonymousSecurityToken and then calls encodeToken, won't that throw an exception because encodeToken doesn't support AnonymousSecurityTokens? doug On 6/13/12 1:50 PM, "btlil...@gmail.com" wrote: > Updated patch to use Anonymous Security Token > > http://codereview.appspot.com/6306074/ >
Re: Pass token on listMethods to enable allowUnauthenticated=false (issue 6306074)
Nice patch. I had overriden AnonymousAuthenticationHandler.getSecurityTokenFromRequest to accomplish the same thing. Now I can back that out. doug On 6/13/12 1:53 PM, "siever...@gmail.com" wrote: > LGTM > > http://codereview.appspot.com/6306074/ >
Re: [VOTE] Release Apache Shindig version 2.5.0-beta2
+1 (non-binding) On 6/12/12 10:41 PM, "Ryan J Baxter" wrote: > I discarded the original staging repo, took in the new fixes, and > regenerated beta2. > > The new staging repo is here: > https://repository.apache.org/content/repositories/orgapacheshindig-232/ > > Also here is the new list of issues fixed in the beta: > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery= > project+%3D+SHINDIG+AND+resolved+%3E%3D+2012-03-26 > > Vote open for 72 hours. > [ ] +1 > [ ] +0 > [ ] -1 > > -Ryan > > > > > From: daviesd > To: , > Date: 06/07/2012 03:51 PM > Subject:Re: [VOTE] Release Apache Shindig version 2.5.0-beta2 > > > > -1 until SHINDIG-1794 is fixed (if deemed necessary for release). > > doug > > > On 6/6/12 9:39 AM, "Ryan J Baxter" wrote: > >> > Hi All, >> > >> > I finished the 2.5.0-beta2 release last night, here is all the info. >> > >> > We solved 52 issues: >> > > https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId= > >> > 12321079 >> > >> > >> > Staging repo: >> > https://repository.apache.org/content/repositories/orgapacheshindig-190/ >> > >> > Tag: >> > > http://svn.apache.org/repos/asf/shindig/tags/shindig-project-2.5.0-beta2/ >> > >> > Vote open for 72 hours. >> > >> > [ ] +1 >> > [ ] +0 >> > [ ] -1 >> > >> > -Ryan > > > >
Re: Shindig snapshots
I¹m not familiar with the continuous build, assembly, and snapshot process for shindig, but it seems like the assemblies are failing (if this is even how the snapshots are created). https://builds.apache.org/job/Shindig%20Assembly/ I found a thread from back in May where this was being addressed. http://shindig-dev.markmail.org/thread/6xhhijzcpyguykl3 Is there anyone besides Paul who can check on why artifacts have not been generated since May 4 (if not I might URGENT him)? Is no one else dependant on snapshots or are you just pulling trunk and creating your own? We use to rely on the the daily snapshots but have been on beta1 for quite a while, so I didn¹t even realize no new artifacts were being generated. doug On 6/11/12 2:34 PM, "daviesd" wrote: > I¹m having issues again getting the latest maven artifacts (I¹ve been using > beta1 for a while now). This is the repository I¹m using (for both beta and > snapshot) > > https://repository.apache.org/content/groups/public/org/apache/shindig > > However the snapshots don¹t seem to have been updated since the beginning of > May. Am I using the wrong location? > > Doug
OAuth2 token expiration and issue times broken
The fix for SHINDIG-1732 introduces a bug with the oauth2 token expires and issue times (or at least a documentation change). The time stored in OAuth2Token use to be in seconds (and is documented that way). Now it¹s storing them in milliseconds in TokenAuthorizationResponseHandler. This causes me to blow up later when I persist them, since I was multiplying by 1000 and the converting it to a Date. What is the correct behavior here? doug
Shindig snapshots
I¹m having issues again getting the latest maven artifacts (I¹ve been using beta1 for a while now). This is the repository I¹m using (for both beta and snapshot) https://repository.apache.org/content/groups/public/org/apache/shindig However the snapshots don¹t seem to have been updated since the beginning of May. Am I using the wrong location? Doug
Re: Using custom @ ids GroupIds throws IllegalArgumentException (issue 6305079)
Not to get greedy about all the stuff I need for beta2, but... :)
Ryan, is this going in before you do the beta2 rebuild?
Thanks for all your help on getting these things resolved so quickly. I'm
still testing this fix, but having maven repo issues this morning, and I was
trying to apply the fix to our environment to make sure it fits in nicely.
doug
On 6/11/12 11:35 AM, "themisty...@gmail.com" wrote:
> Other than the null comment...LGTM
>
> Applied patch and ran tests, all successful.
>
> Ship it!
>
>
> http://codereview.appspot.com/6305079/diff/6001/java/social-api/src/main/java/
> org/apache/shindig/social/opensocial/spi/GroupId.java
> File
> java/social-api/src/main/java/org/apache/shindig/social/opensocial/spi/GroupId
> .java
> (right):
>
> http://codereview.appspot.com/6305079/diff/6001/java/social-api/src/main/java/
> org/apache/shindig/social/opensocial/spi/GroupId.java#newcode128
> java/social-api/src/main/java/org/apache/shindig/social/opensocial/spi/GroupId
> .java:128:
> // return null we don't know the type
> +1
>
> On 2012/06/11 13:48:55, DouglasLDavies wrote:
>> change comment about null
>
> http://codereview.appspot.com/6305079/diff/6001/java/social-api/src/test/java/
> org/apache/shindig/social/opensocial/spi/GroupIdTest.java
> File
> java/social-api/src/test/java/org/apache/shindig/social/opensocial/spi/GroupId
> Test.java
> (right):
>
> http://codereview.appspot.com/6305079/diff/6001/java/social-api/src/test/java/
> org/apache/shindig/social/opensocial/spi/GroupIdTest.java#newcode43
> java/social-api/src/test/java/org/apache/shindig/social/opensocial/spi/GroupId
> Test.java:43:
> GroupId unknown = GroupId.fromJson("@foo");
> I would disagree, seems misleading to call it @custom. @foo
> demonstrates it can be anything and it not just another hardcoded type.
>
> Works either way but I think @foo is a better representation of the
> feature.
>
> On 2012/06/11 13:48:55, DouglasLDavies wrote:
>> Call the variable custom
>
> http://codereview.appspot.com/6305079/
>
Re: GroupId
I had not opened one. I was waiting for Ryan's response to my follow-up.
doug
On 6/8/12 9:16 PM, "Henry Saputra" wrote:
> Hi Doug, do you have a JIRA opened for this issue?
>
> - Henry
>
> On Wed, Jun 6, 2012 at 9:52 AM, daviesd wrote:
>> Some changes were made to GroupId between 2.5-beta1 and 2.5-beta2 that are
>> affecting me.
>>
>> GroupId.Type changed from this
>>
>> ? all, friends, self, deleted, groupId;
>>
>> To this
>>
>> ? objectId(0), self(1), friends(2), all(3);
>>
>> We had extended AppDataService to support a groupId of @institution
>> (something that is relevant in our domain)
>>
>> ? ? ? ? ? ?osapi.appdata.get({
>> ? ? ? ? ? ? ? ?userId: '@me',
>> ? ? ? ? ? ? ? ?groupId : '@institution',
>> ? ? ? ? ? ? ? ?appId : '@app'} )
>>
>> However, I have concerns as to how this will work now, because I¹m fighting
>> through a unit test that does this
>>
>> ? ?groupId = GroupId.fromJson("@institution")
>>
>> And it¹s throwing a IllegalArgumentException.
>>
>> Can some one point me in the right direction as to how I¹m suppose to handle
>> something like this?
>>
>> Thanks,
>> doug
>>
>
Re: Issue with container and security tokens in beta2
Ryan,
Thanks for getting this in beta2. Our gadgets are rendering now. I have
some more testing with oauth2 to make sure nothing broke.
doug
On 6/7/12 8:42 PM, "Ryan J Baxter" wrote:
> Thanks guys!
>
> Paul, should I delete the tag and regenerate it? Or should I port the fix
> to the tag and rebuild the artifacts?
>
>
> -Ryan
>
>
>
>
> From: Stanton Sievers/Westford/IBM@Lotus
> To: dev@shindig.apache.org,
> Date: 06/07/2012 07:08 PM
> Subject:Re: Issue with container and security tokens in beta2
>
>
>
> Committed revision 1347826.
>
> I built and sanity checked that a handful of sample gadgets still rendered
>
> in the sample common container page.
>
> Ryan, let me know if there's anything you need to get the beta2 re-spin
> going.
>
> Thanks,
> -Stanton
>
>
>
> From: Henry Saputra
> To: dev@shindig.apache.org,
> Date: 06/07/2012 17:55
> Subject:Re: Issue with container and security tokens in beta2
>
>
>
> Sweet =)
>
> Yeah Ryan needs to create new RC for beta2 release (sorry Ryan)
>
> - Henry
>
> On Thu, Jun 7, 2012 at 2:11 PM, Stanton Sievers
> wrote:
>> > Not if I assign it to me first! :)
>> >
>> > Doug confirmed the fix works for him. I can deliver it, but then will
>> > Ryan need to re-spin beta2? We only tag for beta2, not branch, right?
>> >
>> > Thanks,
>> > -Stanton
>> >
>> >
>> >
>> > From: Henry Saputra
>> > To: dev@shindig.apache.org,
>> > Date: 06/07/2012 16:55
>> > Subject:Re: Issue with container and security tokens in beta2
>> >
>> >
>> >
>> > Thanks Stanton, can I assign this to you?
>> >
>> > - Henry
>> >
>> > On Thu, Jun 7, 2012 at 1:45 PM, Stanton Sievers
>> > wrote:
>>> >> I updated Doug's JIRA [1] with what I think the code needs to be
> changed
>>> >> to. I haven't tested it, however.
>>> >>
>>> >> [1] https://issues.apache.org/jira/browse/SHINDIG-1794
>>> >>
>>> >> Thanks,
>>> >> -Stanton
>>> >>
>>> >>
>>> >>
>>> >> From: Henry Saputra
>>> >> To: dev@shindig.apache.org,
>>> >> Date: 06/07/2012 16:31
>>> >> Subject:Re: Issue with container and security tokens in beta2
>>> >>
>>> >>
>>> >>
>>> >> Thanks Doug, looks like this check is not right !scriptEls && i <
>>> >> scriptEls.length so the container always set to default
>>> >>
>>> >> - Henry
>>> >>
>>> >> On Thu, Jun 7, 2012 at 12:37 PM, daviesd wrote:
>>>> >>> The for loop in init.js is broken.
>>>> >>>
>>>> >>> If I change
>>>> >>>
>>>> >>> for(var i = 0; !scriptEls && i < scriptEls.length; i++) {
>>>> >>>
>>>> >>> to
>>>> >>>
>>>> >>> for(var i = 0; i < scriptEls.length; i++) {
>>>> >>>
>>>> >>> It fixes the issue and the right container is used.
>>>> >>>
>>>> >>> doug
>>>> >>>
>>>> >>>
>>>> >>> On 6/7/12 3:15 PM, "Stanton Sievers" wrote:
>>>> >>>
>>>>> >>>> Sorry for the spam, one other thought. Do you have any other script
>>> >> tags
>>>>> >>>> that match this regex in your page, Doug? We might be finding the
>>> >> wrong
>>>>> >>>> one that doesn't have the container query param on it.
>>>>> >>>>
>>>>> >>>> Thanks,
>>>>> >>>> -Stanton
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> From: Stanton Sievers/Westford/IBM
>>>>> >>>> To: dev@shindig.apache.org,
>>>>> >>>> Date: 06/07/2012 15:15
>>>>> >>>> Subject:Re: Issue with container and security tokens in beta2
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> Henry,
>>>>> >>&
Re: [VOTE] Release Apache Shindig version 2.5.0-beta2
-1 until SHINDIG-1794 is fixed (if deemed necessary for release). doug On 6/6/12 9:39 AM, "Ryan J Baxter" wrote: > Hi All, > > I finished the 2.5.0-beta2 release last night, here is all the info. > > We solved 52 issues: > https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId= > 12321079 > > > Staging repo: > https://repository.apache.org/content/repositories/orgapacheshindig-190/ > > Tag: > http://svn.apache.org/repos/asf/shindig/tags/shindig-project-2.5.0-beta2/ > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -Ryan
Re: Issue with container and security tokens in beta2
The for loop in init.js is broken.
If I change
for(var i = 0; !scriptEls && i < scriptEls.length; i++) {
to
for(var i = 0; i < scriptEls.length; i++) {
It fixes the issue and the right container is used.
doug
On 6/7/12 3:15 PM, "Stanton Sievers" wrote:
> Sorry for the spam, one other thought. Do you have any other script tags
> that match this regex in your page, Doug? We might be finding the wrong
> one that doesn't have the container query param on it.
>
> Thanks,
> -Stanton
>
>
>
> From: Stanton Sievers/Westford/IBM
> To: dev@shindig.apache.org,
> Date: 06/07/2012 15:15
> Subject:Re: Issue with container and security tokens in beta2
>
>
> Henry,
>
> I think it does match. I executed the folllowing in my firebug console
> and it returned true:
>
> /.*gadgets\/js\/.*container.*[.]js.*[?&]c=1(&|$).*/.test("
> http://ocwms.worldkat.qa.oclc.org/opensocial/gadgets/js/oclccontainer:userpref
> sui:rpc.js?nocache=1&c=1&debug=1&container=oclc
> ");
>
> Doug, can you ensure that your tokens have the correct container in them?
>
> Thanks,
> -Stanton
>
>
>
>
> From: Henry Saputra
> To: dev@shindig.apache.org,
> Date: 06/07/2012 14:55
> Subject:Re: Issue with container and security tokens in beta2
>
>
>
> Actually its maybe in the init.js function initializeGlobalVars()
>
> Looks like the URL
> http://ocwms.worldkat.qa.oclc.org/opensocial/gadgets/js/oclccontainer:userpr
>
> efsui:rpc.js?nocache=1&c=1&debug=1&container=oclc does not contain the
> expected pattern
>
> /.*gadgets\/js\/.*container.*[.]js.*[?&]c=1(&|$).*/
>
>
> - Henry
>
> On Thu, Jun 7, 2012 at 9:30 AM, daviesd wrote:
>> In beta1 I use to see the following flow.
>>
>> Request the javascript using container=oclc
>>
>>
> http://ocwms.worldkat.qa.oclc.org/opensocial/gadgets/js/oclccontainer:userpr
>
>> efsui:rpc.js?nocache=1&c=1&debug=1&container=oclc
>>
>> The iframe request would then look as follows
>>
>>
> http://ocwms.worldkat.qa.oclc.org/opensocial/gadgets/ifr?url=https%3A%2F%2Fw
>
>>
> orldkat.qa.oclc.org%2Fgallery%2Fgadgets%2F40%2Fxml&container=oclc&view=defau
>>
> lt&lang=en&country=US&debug=0&nocache=1&sanitize=0&v=584fb331f9d4272d7164ccf
>>
> e49e0569c&st=oclc%3ATOKEN&testmode=0&parent=http%3A%2F%2Focwms.worldkat.qa.o
>> clc.org&mid=0
>>
>> Notice that the container is CORRECT (oclc). For length purpose I did
> not
>> show the entire length of our security token (it¹s long) so I just put
>> TOKEN.
>>
>> In beta2 I see
>>
>>
> http://platform.oclc.org:8080/opensocial/gadgets/ifr?url=http%3A%2F%2Fplatfo
>
>>
> rm.oclc.org%3A8080%2Fopensocial-demo%2Fgadgets%2Fsettitle.xml&container=defa
>>
> ult&view=default&lang=en&country=US&debug=0&nocache=0&sanitize=0&v=1545d7ce1
>>
> 25d3b0f296d91751cbba444&st=%25st%25&testmode=0&parent=http%3A%2F%2Fplatform.
>> oclc.org%3A8080&mid=0#rpctoken=147042121
>>
>> Notice the container is WRONG (default) and that the ST param is null
>> because when it went to lookup the crypter for the container it was not
>> found (I¹m not sure why default isn¹t found... Still checking on that).
> If
>> I hardcode OCLC at
>>
>>BlobCrypter crypter = crypters.get(aToken.getContainer());
>>
>> In BlobCrypterSecurityTokenCodec when it does the crypter lookup then
>> everything works fine.
>>
>> Does anyone have any ideas what may have changed and where to look?
>>
>> doug
>>
>
>
Re: GroupId
Ryan,
Yes, it would make sense for our use case, but I can also see how it doesn't
fit in with the spec exactly. I'm not 100% sure what an Object-Id is
suppose to be, but I guess we could fall borderline into that category as
well.
In our case specifying @institution tells the shindig apis to use the
institution id that we have encoded into our custom security token. This is
an identifier for all the users of a particular library in our case.
Following the @ convention just felt right from the gadget writer
perspective. We use this in our appdata layer to provide storage for group
type data.
Let us know what you think.
doug
On 6/6/12 8:49 PM, "Ryan J Baxter" wrote:
> Yeah we did a lot of work around Groups to actually support them in
> Shindig. Along the way we found that the Group Id implementation didn't
> exactly follow the spec.
>
> Doug are you basically extending GroupId with your own custom "@" id? We
> didn't consider this case, we basically support the @ ids from the spec
> and then object id, so it makes sense that if you pass another id we throw
> that exception. I think we might have to come up with a way that we can
> allow consumers to extend this...would that make sense for your use case?
>
> -Ryan
>
>
>
>
> From: Henry Saputra
> To: dev@shindig.apache.org,
> Date: 06/06/2012 01:48 PM
> Subject:Re: GroupId
>
>
>
> The change was part of the commits for SHINDIG-1780.
>
> Ryan could probably help with this.
>
> - Henry
>
> On Wed, Jun 6, 2012 at 9:52 AM, daviesd wrote:
>> Some changes were made to GroupId between 2.5-beta1 and 2.5-beta2 that
> are
>> affecting me.
>>
>> GroupId.Type changed from this
>>
>> all, friends, self, deleted, groupId;
>>
>> To this
>>
>> objectId(0), self(1), friends(2), all(3);
>>
>> We had extended AppDataService to support a groupId of @institution
>> (something that is relevant in our domain)
>>
>>osapi.appdata.get({
>>userId: '@me',
>>groupId : '@institution',
>>appId : '@app'} )
>>
>> However, I have concerns as to how this will work now, because I¹m
> fighting
>> through a unit test that does this
>>
>>groupId = GroupId.fromJson("@institution")
>>
>> And it¹s throwing a IllegalArgumentException.
>>
>> Can some one point me in the right direction as to how I¹m suppose to
> handle
>> something like this?
>>
>> Thanks,
>> doug
>>
>
>
Re: Issue with container and security tokens in beta2
Please see my follow up email comparing beta1 to beta2 with pure shindig
(none of my modifications). The problem is demonstrated there (although it
could be user error too).
doug
On 6/7/12 3:12 PM, "Stanton Sievers" wrote:
> Henry,
>
> I think it does match. I executed the folllowing in my firebug console
> and it returned true:
>
> /.*gadgets\/js\/.*container.*[.]js.*[?&]c=1(&|$).*/.test("
> http://ocwms.worldkat.qa.oclc.org/opensocial/gadgets/js/oclccontainer:userpref
> sui:rpc.js?nocache=1&c=1&debug=1&container=oclc
> ");
>
> Doug, can you ensure that your tokens have the correct container in them?
>
> Thanks,
> -Stanton
>
>
>
> From: Henry Saputra
> To: dev@shindig.apache.org,
> Date: 06/07/2012 14:55
> Subject:Re: Issue with container and security tokens in beta2
>
>
>
> Actually its maybe in the init.js function initializeGlobalVars()
>
> Looks like the URL
> http://ocwms.worldkat.qa.oclc.org/opensocial/gadgets/js/oclccontainer:userpr
>
> efsui:rpc.js?nocache=1&c=1&debug=1&container=oclc does not contain the
> expected pattern
>
> /.*gadgets\/js\/.*container.*[.]js.*[?&]c=1(&|$).*/
>
>
> - Henry
>
> On Thu, Jun 7, 2012 at 9:30 AM, daviesd wrote:
>> In beta1 I use to see the following flow.
>>
>> Request the javascript using container=oclc
>>
>>
> http://ocwms.worldkat.qa.oclc.org/opensocial/gadgets/js/oclccontainer:userpr
>
>> efsui:rpc.js?nocache=1&c=1&debug=1&container=oclc
>>
>> The iframe request would then look as follows
>>
>>
> http://ocwms.worldkat.qa.oclc.org/opensocial/gadgets/ifr?url=https%3A%2F%2Fw
>
>>
> orldkat.qa.oclc.org%2Fgallery%2Fgadgets%2F40%2Fxml&container=oclc&view=defau
>>
> lt&lang=en&country=US&debug=0&nocache=1&sanitize=0&v=584fb331f9d4272d7164ccf
>>
> e49e0569c&st=oclc%3ATOKEN&testmode=0&parent=http%3A%2F%2Focwms.worldkat.qa.o
>> clc.org&mid=0
>>
>> Notice that the container is CORRECT (oclc). For length purpose I did
> not
>> show the entire length of our security token (it¹s long) so I just put
>> TOKEN.
>>
>> In beta2 I see
>>
>>
> http://platform.oclc.org:8080/opensocial/gadgets/ifr?url=http%3A%2F%2Fplatfo
>
>>
> rm.oclc.org%3A8080%2Fopensocial-demo%2Fgadgets%2Fsettitle.xml&container=defa
>>
> ult&view=default&lang=en&country=US&debug=0&nocache=0&sanitize=0&v=1545d7ce1
>>
> 25d3b0f296d91751cbba444&st=%25st%25&testmode=0&parent=http%3A%2F%2Fplatform.
>> oclc.org%3A8080&mid=0#rpctoken=147042121
>>
>> Notice the container is WRONG (default) and that the ST param is null
>> because when it went to lookup the crypter for the container it was not
>> found (I¹m not sure why default isn¹t found... Still checking on that).
> If
>> I hardcode OCLC at
>>
>>BlobCrypter crypter = crypters.get(aToken.getContainer());
>>
>> In BlobCrypterSecurityTokenCodec when it does the crypter lookup then
>> everything works fine.
>>
>> Does anyone have any ideas what may have changed and where to look?
>>
>> doug
>>
>
>
Re: Issue with container and security tokens in beta2
Henry/All,
I retested with snapshots of beta1 and beta2 (ruling out all my extensions
in our container).
There is definitely a difference in behavior. In beta1 buildUri gets the
container name right (oclc).
String container = context.getContainer();
In beta2 in gets it wrong (default).
Here are the network requests.
beta1
http://localhost:8080/gadgets/js/container:rpc.js?nocache=1&c=1&debug=1&cont
ainer=oclc
http://localhost:8080/gadgets/ifr?url=http%3A%2F%2Flocalhost%3A8080%2Fsample
container%2Fexamples%2FSocialHelloWorld.xml&container=oclc&view=default&lang
=%25lang%25&country=%25country%25&debug=0&nocache=0&sanitize=%25sanitize%25&
v=eebb355586ff23b9c618f7fa8ff6&st=-1%3A-1%3Ahttp%253A%252F%252Flocalhost
%253A8080%252Fsamplecontainer%252Fexamples%252FSocialHelloWorld.xml%3A*%3Aht
tp%253A%252F%252Flocalhost%253A8080%252Fsamplecontainer%252Fexamples%252FSoc
ialHelloWorld.xml%3A0%3Aoclc%3A1339098219&testmode=0&parent=http%3A%2F%2Floc
alhost%3A8080&mid=0
beta2
http://localhost:8080/gadgets/js/container:rpc.js?nocache=1&c=1&debug=1&cont
ainer=oclc
http://localhost:8080/gadgets/ifr?url=http%3A%2F%2Flocalhost%3A8080%2Fsample
container%2Fexamples%2FSocialHelloWorld.xml&container=default&view=default&l
ang=en&country=US&debug=0&nocache=0&sanitize=%25sanitize%25&v=d5ef46b167d11a
be9a1962131163d6f5&st=-1%3A-1%3Ahttp%253A%252F%252Flocalhost%253A8080%252Fsa
mplecontainer%252Fexamples%252FSocialHelloWorld.xml%3A*%3Ahttp%253A%252F%252
Flocalhost%253A8080%252Fsamplecontainer%252Fexamples%252FSocialHelloWorld.xm
l%3A0%3Adefault%3A1339097193&testmode=0&parent=http%3A%2F%2Flocalhost%3A8080
&mid=0#rpctoken=97245479
In order to test this you need to modify your container.js file as follows
{"gadgets.container" : ["default", "accel", "oclc"]
(or I guess you could just try accel).
I'll keep poking around and try to figure out what set of changes caused
this. Perhaps a unit test for testing this failure is in order.
Is this major enough to hold up beta2? It's a big deal for us because we
use a different container to override some of the behavior of the default
container.
doug
On 6/7/12 1:35 PM, "Henry Saputra" wrote:
> Seems like the iframe URL returned from the metadata call gets the
> wrong container.
>
> Doug, could you debug in the DefaultIframeUriManager.buildUri what is
> the container returned?
>
> - Henry
>
> On Thu, Jun 7, 2012 at 9:30 AM, daviesd wrote:
>> In beta1 I use to see the following flow.
>>
>> Request the javascript using container=oclc
>>
>> http://ocwms.worldkat.qa.oclc.org/opensocial/gadgets/js/oclccontainer:userpr
>> efsui:rpc.js?nocache=1&c=1&debug=1&container=oclc
>>
>> The iframe request would then look as follows
>>
>> http://ocwms.worldkat.qa.oclc.org/opensocial/gadgets/ifr?url=https%3A%2F%2Fw
>> orldkat.qa.oclc.org%2Fgallery%2Fgadgets%2F40%2Fxml&container=oclc&view=defau
>> lt&lang=en&country=US&debug=0&nocache=1&sanitize=0&v=584fb331f9d4272d7164ccf
>> e49e0569c&st=oclc%3ATOKEN&testmode=0&parent=http%3A%2F%2Focwms.worldkat.qa.o
>> clc.org&mid=0
>>
>> Notice that the container is CORRECT (oclc). ?For length purpose I did not
>> show the entire length of our security token (it¹s long) so I just put
>> TOKEN.
>>
>> In beta2 I see
>>
>> http://platform.oclc.org:8080/opensocial/gadgets/ifr?url=http%3A%2F%2Fplatfo
>> rm.oclc.org%3A8080%2Fopensocial-demo%2Fgadgets%2Fsettitle.xml&container=defa
>> ult&view=default&lang=en&country=US&debug=0&nocache=0&sanitize=0&v=1545d7ce1
>> 25d3b0f296d91751cbba444&st=%25st%25&testmode=0&parent=http%3A%2F%2Fplatform.
>> oclc.org%3A8080&mid=0#rpctoken=147042121
>>
>> Notice the container is WRONG (default) and that the ST param is null
>> because when it went to lookup the crypter for the container it was not
>> found (I¹m not sure why default isn¹t found... Still checking on that). ?If
>> I hardcode OCLC at
>>
>> ? ?BlobCrypter crypter = crypters.get(aToken.getContainer());
>>
>> In BlobCrypterSecurityTokenCodec when it does the crypter lookup then
>> everything works fine.
>>
>> Does anyone have any ideas what may have changed and where to look?
>>
>> doug
>>
>
Issue with container and security tokens in beta2
In beta1 I use to see the following flow. Request the javascript using container=oclc http://ocwms.worldkat.qa.oclc.org/opensocial/gadgets/js/oclccontainer:userpr efsui:rpc.js?nocache=1&c=1&debug=1&container=oclc The iframe request would then look as follows http://ocwms.worldkat.qa.oclc.org/opensocial/gadgets/ifr?url=https%3A%2F%2Fw orldkat.qa.oclc.org%2Fgallery%2Fgadgets%2F40%2Fxml&container=oclc&view=defau lt&lang=en&country=US&debug=0&nocache=1&sanitize=0&v=584fb331f9d4272d7164ccf e49e0569c&st=oclc%3ATOKEN&testmode=0&parent=http%3A%2F%2Focwms.worldkat.qa.o clc.org&mid=0 Notice that the container is CORRECT (oclc). For length purpose I did not show the entire length of our security token (it¹s long) so I just put TOKEN. In beta2 I see http://platform.oclc.org:8080/opensocial/gadgets/ifr?url=http%3A%2F%2Fplatfo rm.oclc.org%3A8080%2Fopensocial-demo%2Fgadgets%2Fsettitle.xml&container=defa ult&view=default&lang=en&country=US&debug=0&nocache=0&sanitize=0&v=1545d7ce1 25d3b0f296d91751cbba444&st=%25st%25&testmode=0&parent=http%3A%2F%2Fplatform. oclc.org%3A8080&mid=0#rpctoken=147042121 Notice the container is WRONG (default) and that the ST param is null because when it went to lookup the crypter for the container it was not found (I¹m not sure why default isn¹t found... Still checking on that). If I hardcode OCLC at BlobCrypter crypter = crypters.get(aToken.getContainer()); In BlobCrypterSecurityTokenCodec when it does the crypter lookup then everything works fine. Does anyone have any ideas what may have changed and where to look? doug
Re: [VOTE] Release Apache Shindig version 2.5.0-beta2
Ryan, I'd love to +1 but I'm still having some integration issues (I'm composing a separate email for the GroupId issue). I'm also getting the dreaded "HTTP Status 401 - Malformed security token %st%Invalid security token %st% " I think when a gadget makes a request to the container (Flash gadgets work). Still drilling down into that one. Lots of fun changes from beta1 to beta2 which is proof that I ought to keep a separate development stream going on trunk so I find these issues sooner. doug On 6/6/12 9:39 AM, "Ryan J Baxter" wrote: > Hi All, > > I finished the 2.5.0-beta2 release last night, here is all the info. > > We solved 52 issues: > https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId= > 12321079 > > > Staging repo: > https://repository.apache.org/content/repositories/orgapacheshindig-190/ > > Tag: > http://svn.apache.org/repos/asf/shindig/tags/shindig-project-2.5.0-beta2/ > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -Ryan
GroupId
Some changes were made to GroupId between 2.5-beta1 and 2.5-beta2 that are
affecting me.
GroupId.Type changed from this
all, friends, self, deleted, groupId;
To this
objectId(0), self(1), friends(2), all(3);
We had extended AppDataService to support a groupId of @institution
(something that is relevant in our domain)
osapi.appdata.get({
userId: '@me',
groupId : '@institution',
appId : '@app'} )
However, I have concerns as to how this will work now, because I¹m fighting
through a unit test that does this
groupId = GroupId.fromJson("@institution")
And it¹s throwing a IllegalArgumentException.
Can some one point me in the right direction as to how I¹m suppose to handle
something like this?
Thanks,
doug
Re: [VOTE] Release Apache Shindig version 2.5.0-beta2
That first link does not work for me (IssueNavigator). I get The selected filter is not available to you, perhaps it has been deleted or had its permissions changed. Also, do you know if SHINDIG-1787 made it in? doug On 6/6/12 9:39 AM, "Ryan J Baxter" wrote: > Hi All, > > I finished the 2.5.0-beta2 release last night, here is all the info. > > We solved 52 issues: > https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId= > 12321079 > > > Staging repo: > https://repository.apache.org/content/repositories/orgapacheshindig-190/ > > Tag: > http://svn.apache.org/repos/asf/shindig/tags/shindig-project-2.5.0-beta2/ > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -Ryan
Re: Review Request: Jira 1732 and lots of other fixes/enhancements
>> Some of these changes are interface changes/additions/deletions and could effect custom consumer extensions. (Probably unlikely because nobody has complained about them yet.) << Ugh... I should have been keeping up with this. Yes the interface changes affect us big time moving from beta1 to beta2. So chalk up one complaint. :) doug On 5/9/12 8:49 PM, "Stanton Sievers" wrote: > > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/4947/#review7754 > --- > > Ship it! > > > Committed revision 1336461 > > Please close the review. > > - Stanton > > > On 2012-05-04 14:31:05, Adam Clarke wrote: >> > >> > --- >> > This is an automatically generated e-mail. To reply, visit: >> > https://reviews.apache.org/r/4947/ >> > --- >> > >> > (Updated 2012-05-04 14:31:05) >> > >> > >> > Review request for shindig, Ryan Baxter and Brian Lillie. >> > >> > >> > Summary >> > --- >> > >> > When the original OAuth2 Consumer was added the patch was quite large and >> it was tough to get a comprehensive review. It was expected that there >> would be a couple of revisions to address problems. >> > >> > This patch contains the changes for Jira 173. Due to time constraints it >> also contains a number of other fixes/enhancements found in internal OAuth2 >> Consumer reviews and testing. >> > >> > Some of these changes are interface changes/additions/deletions and could >> effect custom consumer extensions. (Probably unlikely because nobody has >> complained about them yet.) >> > >> > >> > Patch Includes: >> > 0) More standard formatting and checkstyle in modified files. >> > >> > 1) Jira 1732 for restricted OAuth2 endpoints. >> > >> > 2) Rework of OAuth2Cache and the default InMemoryCache. Tried to get too >> cute with the original which made it very hard to implement. New version is >> much easier to implement with your own Maps. >> > >> > 3) OAuth2 State encryption/decryption. Wasn't absolutely necessary for >> OAuth2, but added it for consistency with OAuth1 and for the peace-of-mind of >> security types. >> > >> > 4) BasicOAuth2Request no longer sends expired tokens. The previous impl >> relied on the OAuth2 Service Provider returning 401 when a expired token was >> used. This led to a nasty user experience when a service provider violated >> the spec and returned something other than 401. OAuth2 Consumer no longer >> sends expired tokens and reacts as if the server returned the 401. >> > >> > 5) OAuth2Persister had an unnecessary method to create a token. This is >> now handled in the OAuth2Store. >> > >> > 6) Caching and OAuth2Store.init() fixes for better behavior in a clustered >> environment. >> > >> > 7) Properly handle the URL %scheme% for the redirect uri (aka callback url) >> > >> > >> > This addresses bug SHINDIG-1732. >> > https://issues.apache.org/jira/browse/SHINDIG-1732 >> > >> > >> > Diffs >> > - >> > >> > >> http://svn.apache.org/repos/asf/shindig/trunk/java/common/conf/shindig.proper >> ties 1333970 >> > >> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/ >> apache/shindig/gadgets/oauth2/BasicOAuth2Accessor.java 1333970 >> > >> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/ >> apache/shindig/gadgets/oauth2/BasicOAuth2Request.java 1333970 >> > >> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/ >> apache/shindig/gadgets/oauth2/BasicOAuth2Store.java 1333970 >> > >> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/ >> apache/shindig/gadgets/oauth2/OAuth2Accessor.java 1333970 >> > >> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/ >> apache/shindig/gadgets/oauth2/OAuth2CallbackState.java PRE-CREATION >> > >> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/ >> apache/shindig/gadgets/oauth2/OAuth2CallbackStateToken.java PRE-CREATION >> > >> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/ >> apache/shindig/gadgets/oauth2/OAuth2Error.java 1333970 >> > >> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/ >> apache/shindig/gadgets/oauth2/OAuth2FetcherConfig.java 1333970 >> > >> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/ >> apache/shindig/gadgets/oauth2/OAuth2Message.java 1333970 >> > >> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/ >> apache/shindig/gadgets/oauth2/OAuth2Module.java 1333970 >> > >> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/ >> apache/shindig/gadgets/oauth2/OAuth2Store.java 1333970 >> > >> http://svn.apache.org/repos/asf/shindig/trunk/
Re: requestNavigateTo and beta1 v.s. trunk differences
Ryan,
Thank You Thank You Thank You. I will try what you suggest with the
buffering, but I'm not sure I want that as a long term solution.
doug
On 6/1/12 2:55 PM, "Ryan J Baxter" wrote:
> This is certainly a bug, I can reproduce it in the common container as
> well. After stepping through the code I think I figured out what is
> happening, basically when you switch views after the initial load in the
> GadgetSite code both the currentGadgetHolder and the loadingGadgetHolder
> are set to a GadgetHolder pointing to the same DOM element. When we call
> GadgetSite.onRender when switching views we first call
> currentGadgetHolder.dispose which removes the element from the DOM and
> then we finally set currentGadgetHolder to loadingGadgetHolder. Problem
> is since the currentGadgetHolder and the loadingGadgetHolder point to the
> same DOM element we end up removing the iframe which contained the new
> view.
>
> I THINK if you supply a separate buffering element when you create your
> site you would not run into this problem, you can certainly give that a
> shot and see if that works. If there is no buffering element the site
> will use the element in which the gadget is currently rendered in when
> creating the loadingGadgetHolder, which leads to the problem we are
> seeing.
>
> I reverted the changes Henry made in this review,
> https://reviews.apache.org/r/4486/ and the problem goes away. Henry can
> you take a look at this? I am pretty sure it is the changes in
> SiteHolder.dispose that are causing the problem here. While I think using
> a buffering element would solve the problem, the API (at this point)
> indicates the buffering element is optional, so everything should work
> without it.
>
> -Ryan
>
>
>
>
> From: daviesd
> To: ,
> Date: 06/01/2012 11:30 AM
> Subject:Re: requestNavigateTo and beta1 v.s. trunk differences
>
>
>
> Ya, that was my first thought. But inspecting with firebug reveals that
> there is not even any content from the view navigated to. Even if I
> change
> the code to
>
> container.navigateGadget( site, url, [], {} );
>
> It doesn't re-navigate to the default view again (even though that how I
> rendered the gadget in the first place).
>
> I'll double check on the adjustHeight stuff, but I don't think that is it.
>
> Thanks Ryan (btw... I watched some of your youtube opensocial sandbox
> videos
> yesterday... very nice).
>
> doug
>
>
> On 6/1/12 11:18 AM, "Ryan J Baxter" wrote:
>
>> Doug, does the gadget call adjustHeight? There were changes that went
>> into Shindig [1] [2] that changed some of the CSS inside the gadgets
>> iframe to allow the inter content to scroll. We noticed in some of our
>> containers that we had to alter the CSS on our gadget sites to make
> things
>> work properly. Is there content actually in the site? Maybe the
>> adjustHeight call is not working / the CSS for the site element needs to
>> change.
>>
>>
>> [1] https://issues.apache.org/jira/browse/SHINDIG-1766
>> [2] https://issues.apache.org/jira/browse/SHINDIG-1767
>>
>> -Ryan
>>
>>
>>
>>
>> From: daviesd
>> To: shindig ,
>> Date: 06/01/2012 10:58 AM
>> Subject:Re: requestNavigateTo and beta1 v.s. trunk differences
>>
>>
>>
>> Doh! It¹s Friday. I guess I should have described the symptoms. I end
> up
>> with a gadget with no content area (collapsed).
>>
>>
>> On 6/1/12 10:50 AM, "daviesd" wrote:
>>
>>> Does anyone (Dan?) have any idea why this code
>>>
>>> container.rpcRegister("requestNavigateTo", function
>>> requestNavigateTo(rpcArgs, view, params) {
>>>
>>> var site = rpcArgs[osapi.container.GadgetSite.RPC_ARG_KEY],
>>> url = site.getActiveSiteHolder().getUrl(),
>>> renderParams = {};
>>>
>>> renderParams[osapi.container.RenderParam.VIEW] = view;
>>> container.navigateGadget( site, url, params, renderParams );
>>> });
>>>
>>> doesn¹t work with the latest 2.5 snapshot? We¹ve been using beta1
> since
>> it
>>> was created, but will all the activity for beta2 I thought I ought to
>> get a
>>> jump start and see what broke for us. This worked in beta1. I¹ve
>> logged the
>>> site, url, and view and they all seem legit.
>>>
>>> doug
>>
>>
>
>
>
Re: requestNavigateTo and beta1 v.s. trunk differences
Ya, that was my first thought. But inspecting with firebug reveals that
there is not even any content from the view navigated to. Even if I change
the code to
container.navigateGadget( site, url, [], {} );
It doesn't re-navigate to the default view again (even though that how I
rendered the gadget in the first place).
I'll double check on the adjustHeight stuff, but I don't think that is it.
Thanks Ryan (btw... I watched some of your youtube opensocial sandbox videos
yesterday... very nice).
doug
On 6/1/12 11:18 AM, "Ryan J Baxter" wrote:
> Doug, does the gadget call adjustHeight? There were changes that went
> into Shindig [1] [2] that changed some of the CSS inside the gadgets
> iframe to allow the inter content to scroll. We noticed in some of our
> containers that we had to alter the CSS on our gadget sites to make things
> work properly. Is there content actually in the site? Maybe the
> adjustHeight call is not working / the CSS for the site element needs to
> change.
>
>
> [1] https://issues.apache.org/jira/browse/SHINDIG-1766
> [2] https://issues.apache.org/jira/browse/SHINDIG-1767
>
> -Ryan
>
>
>
>
> From: daviesd
> To: shindig ,
> Date: 06/01/2012 10:58 AM
> Subject:Re: requestNavigateTo and beta1 v.s. trunk differences
>
>
>
> Doh! It¹s Friday. I guess I should have described the symptoms. I end up
> with a gadget with no content area (collapsed).
>
>
> On 6/1/12 10:50 AM, "daviesd" wrote:
>
>> Does anyone (Dan?) have any idea why this code
>>
>> container.rpcRegister("requestNavigateTo", function
>> requestNavigateTo(rpcArgs, view, params) {
>>
>> var site = rpcArgs[osapi.container.GadgetSite.RPC_ARG_KEY],
>> url = site.getActiveSiteHolder().getUrl(),
>> renderParams = {};
>>
>> renderParams[osapi.container.RenderParam.VIEW] = view;
>> container.navigateGadget( site, url, params, renderParams );
>> });
>>
>> doesn¹t work with the latest 2.5 snapshot? We¹ve been using beta1 since
> it
>> was created, but will all the activity for beta2 I thought I ought to
> get a
>> jump start and see what broke for us. This worked in beta1. I¹ve
> logged the
>> site, url, and view and they all seem legit.
>>
>> doug
>
>
Re: requestNavigateTo and beta1 v.s. trunk differences
Doh! It¹s Friday. I guess I should have described the symptoms. I end up
with a gadget with no content area (collapsed).
On 6/1/12 10:50 AM, "daviesd" wrote:
> Does anyone (Dan?) have any idea why this code
>
> container.rpcRegister("requestNavigateTo", function
> requestNavigateTo(rpcArgs, view, params) {
>
> var site = rpcArgs[osapi.container.GadgetSite.RPC_ARG_KEY],
> url = site.getActiveSiteHolder().getUrl(),
> renderParams = {};
>
> renderParams[osapi.container.RenderParam.VIEW] = view;
> container.navigateGadget( site, url, params, renderParams );
> });
>
> doesn¹t work with the latest 2.5 snapshot? We¹ve been using beta1 since it
> was created, but will all the activity for beta2 I thought I ought to get a
> jump start and see what broke for us. This worked in beta1. I¹ve logged the
> site, url, and view and they all seem legit.
>
> doug
requestNavigateTo and beta1 v.s. trunk differences
Does anyone (Dan?) have any idea why this code
container.rpcRegister("requestNavigateTo", function
requestNavigateTo(rpcArgs, view, params) {
var site = rpcArgs[osapi.container.GadgetSite.RPC_ARG_KEY],
url = site.getActiveSiteHolder().getUrl(),
renderParams = {};
renderParams[osapi.container.RenderParam.VIEW] = view;
container.navigateGadget( site, url, params, renderParams );
});
doesn¹t work with the latest 2.5 snapshot? We¹ve been using beta1 since it
was created, but will all the activity for beta2 I thought I ought to get a
jump start and see what broke for us. This worked in beta1. I¹ve logged
the site, url, and view and they all seem legit.
doug
Re: [PROPOSAL] Monthly Beta Releases
I would agree. I'm scared to death with the number of changes that have been made between the beta we are using and the next one. :) On 5/18/12 10:06 AM, "Franklin, Matthew B." wrote: > There are quite a few of us Shindig users who are unable to depend on SNAPSHOT > releases or trunk code. As great new bug fixes and features rapidly make > their way into Shindig, we would like to consume them on a more regular basis. > Therefore, I would like to propose that a beta release is spun on a monthly > cadence. > > Thoughts? > > -Matt >
Re: Does data-pipelining in proxied content require oauth to be configured?
Henry, Thanks. I tried that and I still had trouble. However if I switch to Then it works without signing. doug On 4/27/12 2:09 PM, "Henry Saputra" wrote: > I think you can workaround this by instead of using @viewer in the > data pipeline use the actual user id instead. > > - Henry > >
Re: Does data-pipelining in proxied content require oauth to be configured?
No, I do not. That's my problem. If I want to do data-pipelining it looks
like I can't do that without signing. Argh... Ok... I think I'm stuck for
now then.
On 4/27/12 1:47 PM, "Henry Saputra" wrote:
> Shindig does not store consumer key for gadgets by default so we need
> to override the default SHindig OAuth store for it.
>
> Doug, I assume you have your own OAuth store/provider for your OAuth flow?
>
> - Henry
>
> On Fri, Apr 27, 2012 at 8:20 AM, daviesd wrote:
>> Here's the logic in View.java
>>
>> ? ?if (needViewer && (!this.signViewer || this.authType == AuthType.NONE))
>> {
>> ? ? ?throw new SpecParserException("Must sign by viewer to request
>> viewer.");
>> ? ?}
>>
>> needsViewer is set IF data-pipelining has a userId of @viewer which
>>
>>
>>
>> Would be requiring.
>>
>> So this tells me that any data-pipelining that deals with viewer needs to be
>> signed (or I'm missing something).
>>
>> If that's true, then I'm stumped on the 403 error I get back when I enable
>> signing, because then it appears from the consumer key error that I need to
>> have oauth enabled.
>>
>> doug
>>
>>
>> On 4/26/12 6:35 PM, "Ryan J Baxter" wrote:
>>
>>> Doug, I have not tried this in a while, but last time I did OAuth was not
>>> required.
>>>
>>> -Ryan
>>>
>>>
>>>
>>>
>>> From: ? daviesd
>>> To: ? ? shindig ,
>>> Date: ? 04/26/2012 06:13 PM
>>> Subject: ? ? ? ?Does data-pipelining in proxied content require oauth to
>>> be configured?
>>>
>>>
>>>
>>> I have a developer trying to use proxied content. ?Their gadget looks as
>>> follows:
>>>
>>> ? ? >> ? ? ?href="http://localhost/some.php";
>>> ? ? ?type="html"
>>> ? ? ?authz="signed"
>>> ? ? ?xmlns:os="http://ns.opensocial.org/2008/markup";>
>>> ? ? ? ? ? ?
>>> ? ?
>>>
>>> We keep getting a 403 back from the server
>>>
>>> WARNING: The following fatal error occurred when OAuth was fetching
>>> content:
>>> ?Unable to retrieve consumer key.
>>> Apr 26, 2012 6:04:38 PM org.apache.shindig.gadgets.render.Renderer render
>>> INFO: The gadget at http://dl.dropbox.com/u/x/gadgets/karen_proxy.xml
>>> did not render. The following error occurred: Unable to reach remote host.
>>> HTTP status 403.
>>>
>>> If we set authz to none then we get ³Must sign by viewer to request
>>> viewer².
>>>
>>> So I¹m assuming you must turn authz on for data-pipelining to work. ?Does
>>> this mean I need to configure oauth in shindig.properties? ?I don¹t
>>> currently and this is probably my problem, but just checking.
>>>
>>> doug
>>>
>>>
>>
>>
>
Re: Does data-pipelining in proxied content require oauth to be configured?
Here's the logic in View.java
if (needViewer && (!this.signViewer || this.authType == AuthType.NONE))
{
throw new SpecParserException("Must sign by viewer to request
viewer.");
}
needsViewer is set IF data-pipelining has a userId of @viewer which
Would be requiring.
So this tells me that any data-pipelining that deals with viewer needs to be
signed (or I'm missing something).
If that's true, then I'm stumped on the 403 error I get back when I enable
signing, because then it appears from the consumer key error that I need to
have oauth enabled.
doug
On 4/26/12 6:35 PM, "Ryan J Baxter" wrote:
> Doug, I have not tried this in a while, but last time I did OAuth was not
> required.
>
> -Ryan
>
>
>
>
> From: daviesd
> To: shindig ,
> Date: 04/26/2012 06:13 PM
> Subject:Does data-pipelining in proxied content require oauth to
> be configured?
>
>
>
> I have a developer trying to use proxied content. Their gadget looks as
> follows:
>
> href="http://localhost/some.php";
> type="html"
> authz="signed"
> xmlns:os="http://ns.opensocial.org/2008/markup";>
>
>
>
> We keep getting a 403 back from the server
>
> WARNING: The following fatal error occurred when OAuth was fetching
> content:
> Unable to retrieve consumer key.
> Apr 26, 2012 6:04:38 PM org.apache.shindig.gadgets.render.Renderer render
> INFO: The gadget at http://dl.dropbox.com/u/x/gadgets/karen_proxy.xml
> did not render. The following error occurred: Unable to reach remote host.
> HTTP status 403.
>
> If we set authz to none then we get ³Must sign by viewer to request
> viewer².
>
> So I¹m assuming you must turn authz on for data-pipelining to work. Does
> this mean I need to configure oauth in shindig.properties? I don¹t
> currently and this is probably my problem, but just checking.
>
> doug
>
>
Does data-pipelining in proxied content require oauth to be configured?
I have a developer trying to use proxied content. Their gadget looks as follows: http://localhost/some.php"; type="html" authz="signed" xmlns:os="http://ns.opensocial.org/2008/markup";> We keep getting a 403 back from the server WARNING: The following fatal error occurred when OAuth was fetching content: Unable to retrieve consumer key. Apr 26, 2012 6:04:38 PM org.apache.shindig.gadgets.render.Renderer render INFO: The gadget at http://dl.dropbox.com/u/x/gadgets/karen_proxy.xml did not render. The following error occurred: Unable to reach remote host. HTTP status 403. If we set authz to none then we get ³Must sign by viewer to request viewer². So I¹m assuming you must turn authz on for data-pipelining to work. Does this mean I need to configure oauth in shindig.properties? I don¹t currently and this is probably my problem, but just checking. doug
oauth2 dance
A quick yes or no question which is plaguing us right now. Does an oauth2 enabled gadget ALWAYS have to do the popup oauth2 dance? In other words, there is no way to make a service call without first having a user click the authorization url and the authorization server redirecting the browser back to the redirect uri. Correct? Is there a way to do this automatically (but then I suspect you¹d get a browser warning). And if you don¹t share the access token across multiple services, then you¹d have to go through the oauth2 dance for each type of service??? Ok, maybe not a simple yes/no answer. :) doug
Re: [VOTE][RESULT] Apache Shindig release 2.5.0-beta1
Thanks. Working now. On 3/30/12 2:59 PM, "Paul Lindner" wrote: > weird, I went back and checked and it wasn't listed as released. > > Tried now, and will check back in a while to see if it's properly working. > > > On Fri, Mar 30, 2012 at 6:26 AM, daviesd wrote: > >> Thanks Paul. >> >> I've always used >> >> https://repository.apache.org/content/groups/public >> >> To pick up the beta in the past. Am I using the wrong location? I don't >> see 2.5.0-beta1, but I see the 3.0.0 betas. >> >> doug >> >> >> On 3/29/12 4:31 PM, "Paul Lindner" wrote: >> >>> I just published the repo to maven. Will update jira in a moment. >>> >>> >>> On Thu, Mar 29, 2012 at 12:19 PM, Henry Saputra >>> wrote: >>> >>>> Thanks for time to verify the release candidate. >>>> >>>> The VOTE results are in: >>>> >>>> +1 binding: Stanton, Jesse, Ryan, Paul, Henry >>>> +1 non-binding: Franklin, Ate, Doug >>>> >>>> No -1 and 0 votes. >>>> >>>> The release candidate is passed. Paul will continue with the release >>>> process. >>>> >>>> Thanks again for all the help to vet this release candidate. >>>> >>>> - Henry >>>> >>>> On Mon, Mar 26, 2012 at 11:25 AM, Henry Saputra < >> henry.sapu...@gmail.com> >>>> wrote: >>>>> Hi All, >>>>> >>>>> Paul Lindner has prepared a release candidate for Shindig 2.5.0-beta1. >>>>> >>>>> Staging repo: >>>>> >>>> >> https://repository.apache.org/content/repositories/orgapacheshindig-114/ >>>>> >>>>> SVN tag: >>>>> >>>> >> http://svn.apache.org/repos/asf/shindig/tags/shindig-project-2.5.0-beta1/ >>>>> >>>>> Keys: >>>>> >>>> >> http://svn.apache.org/repos/asf/shindig/tags/shindig-project-2.5.0-beta1/KEYS >>>>> >>>>> Vote open for 72 hours. >>>>> >>>>> [ ] +1 >>>>> [ ] +0 >>>>> [ ] -1 >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> Henry >>>> >>> >>> >> >> >> >
Re: [VOTE][RESULT] Apache Shindig release 2.5.0-beta1
Thanks Paul. I've always used https://repository.apache.org/content/groups/public To pick up the beta in the past. Am I using the wrong location? I don't see 2.5.0-beta1, but I see the 3.0.0 betas. doug On 3/29/12 4:31 PM, "Paul Lindner" wrote: > I just published the repo to maven. Will update jira in a moment. > > > On Thu, Mar 29, 2012 at 12:19 PM, Henry Saputra > wrote: > >> Thanks for time to verify the release candidate. >> >> The VOTE results are in: >> >> +1 binding: Stanton, Jesse, Ryan, Paul, Henry >> +1 non-binding: Franklin, Ate, Doug >> >> No -1 and 0 votes. >> >> The release candidate is passed. Paul will continue with the release >> process. >> >> Thanks again for all the help to vet this release candidate. >> >> - Henry >> >> On Mon, Mar 26, 2012 at 11:25 AM, Henry Saputra >> wrote: >>> Hi All, >>> >>> Paul Lindner has prepared a release candidate for Shindig 2.5.0-beta1. >>> >>> Staging repo: >>> >> https://repository.apache.org/content/repositories/orgapacheshindig-114/ >>> >>> SVN tag: >>> >> http://svn.apache.org/repos/asf/shindig/tags/shindig-project-2.5.0-beta1/ >>> >>> Keys: >>> >> http://svn.apache.org/repos/asf/shindig/tags/shindig-project-2.5.0-beta1/KEYS >>> >>> Vote open for 72 hours. >>> >>> [ ] +1 >>> [ ] +0 >>> [ ] -1 >>> >>> Thanks, >>> >>> >>> Henry >> > >
Re: [VOTE] Apache Shindig release 2.5.0-beta1
Ideas if this will get released before the weekend? Thanks, doug On 3/26/12 2:25 PM, "Henry Saputra" wrote: > Hi All, > > Paul Lindner has prepared a release candidate for Shindig 2.5.0-beta1. > > Staging repo: > https://repository.apache.org/content/repositories/orgapacheshindig-114/ > > SVN tag: > http://svn.apache.org/repos/asf/shindig/tags/shindig-project-2.5.0-beta1/ > > Keys: > http://svn.apache.org/repos/asf/shindig/tags/shindig-project-2.5.0-beta1/KEYS > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > Thanks, > > > Henry >
Gadget Lifecyle Event vs. Container Lifecyle Events
I know there is discussion about this topic over on the OpenSocial and Gadgets Specification google group. So please let me know if I¹m polluting this maillist with something that shouldn¹t be discussed here. I¹ve been pretty familiar with the container lifecycle events available via addGadgetLifecycleCallback and have plugged into some of them (onNavigated). Until recently I didn¹t even know about the gadget lifecycle events ( http://opensocial-resources.googlecode.com/svn/spec/trunk/Core-Gadget.xml#Li feCycleEvents ). First off does shindig even support these? (I think Jiho Hwang just asked a similar question -- http://markmail.org/message/3zk3pr2dabkf7pem). Next, it seems like this is really for gadget developers to provide restful callbacks so that they can track their own apps and not for me as a container developer to track anything. However, I have the need as a container developer to start tracking some of these events. For example a gadget has been installed/uninstalled (whatever that means). Should I just being doing this from within each of my specialized container functions (where I actually install an app and use our spaces implementation) or is there a similar container callback approach that I can plug into? I hope that makes sense. Thanks, Doug
Re: Shindig running on different domain than container REVISITED
to embed all of the data that common container usually
>> tries to fetch via XHR directly into the initial response of your
>> container page.
>>
>> That's the way we do it in Rave and IMO it works out nicely -- although it
>> is a little more work to implement it that way. You need code in your
>> container implementation which generates security tokens and also fetches
>> gadget metadata from Shindig -- but then with that in place you can embed
>> the tokens and metadata into the container page response for each gadget
>> the user has on their page and before you try to navigate each gadget you
>> can use the common container API's to push those embedded tokens and
>> metadata into the common container cache. You can also cache the gadget
>> metadata in your custom container so that you don't have to fetch it from
>> Shindig on every request.
>>
>> Doing this eliminates the need for common container to talk directly to
>> Shindig so then running Shindig on a different domain is no longer an
>> issue. It also cuts down on the number of network requests needed to get
>> a page of gadgets rendered which is a nice side effect (which was the real
>> reason we did it that way in Rave in the first place).
>>
>> --Jesse
>>
>>> -Original Message-
>>> From: Ryan J Baxter [mailto:rjbax...@us.ibm.com]
>>> Sent: Monday, March 26, 2012 8:16 PM
>>> To: dev@shindig.apache.org
>>> Subject: Re: Shindig running on different domain than container REVISITED
>>>
>>> Doug, I was also hacking up some code the other day that may be
>>> related.
>>>
>>> Instead of setting the API_HOST and API_PATH to go through the proxy, you
>>> can setup a transparent proxy running on the containers domain to just
>>> "forward" the requests on to the Shindig server. The proxy I was using
>>> was the one provided by Jetty, which may be convenient if you are using
>>> Jetty to run you app :)
>>>
>>> http://docs.codehaus.org/display/JETTY/Asynchronous+Proxy+Servlet
>>>
>>>
>>> -Ryan
>>>
>>>
>>>
>>>
>>> From: daviesd
>>> To: ,
>>> Date: 03/26/2012 04:58 PM
>>> Subject:Re: Shindig running on different domain than container
>>> REVISITED
>>>
>>>
>>>
>>> One other thing (if it helps). I see gadgets that don't do makeRequest
>>> fail
>>> as follows:
>>>
>>> Unsafe JavaScript attempt to access frame with URL
>>> http://localhost:9090/opensocial-demo/testcontainer/ from frame with URL
>>> http://localhost:8080/opensocial/gadgets/ifr?url=http%3A%2F%2Fhosting.g
>> m
>>> odul
>>>
>>> es.com%2Fig%2Fgadgets%2Ffile%2F112581010116074801021%2Fhamster.xm
>> l
>>> &container
>>> =default&view=default&lang=%25lang%25&country=%25country%25&debu
>> g
>>> =0&nocache=
>>> 0&sanitize=%25sanitize%25&v=d699982ddc921667a106a76c22bc8e22&testm
>> o
>>> de=0&pare
>>> nt=http%3A%2F%2Flocalhost%3A9090&mid=0#up_hamsterName=%25up_h
>> a
>>> msterName%25&u
>>> p_bgColor=%25up_bgColor%25&up_bodyColor=%25up_bodyColor%25&up_
>> e
>>> arColor=%25up
>>> _earColor%25&up_snoutColor=%25up_snoutColor%25&up_eyeColor=%25u
>> p
>>> _eyeColor%25
>>> &up_feetColor=%25up_feetColor%25&up_tailColor=%25up_tailColor%25&u
>> p
>>> _waterCol
>>> or=%25up_waterColor%25&up_foodColor=%25up_foodColor%25&up_whe
>> el
>>> Color=%25up_w
>>> heelColor%25&up_wheelOuterColor=%25up_wheelOuterColor%25&up_wh
>> e
>>> elCenterColor
>>> =%25up_wheelCenterColor%25&up_wheelSpokeColor=%25up_wheelSpok
>> e
>>> Color%25.
>>> Domains, protocols and ports must match.
>>>
>>> So it's obvious I'm gonna have lots of issues getting this working. Is
>>> cross-domain support on the roadmap anywhere? I can try to tackle this
>>> but
>>> if it's on someone's roadmap I'll live with the proxy solution in the
>>> meantime.
>>>
>>> doug
>>>
>>>
>>> On 3/26/12 4:38 PM, "daviesd" wrote:
>>>
>>>> Ok, one step forward. If I add
>>>>
>>>> servletResponse.addHeader("Access-Control-Allow-Headers",
>>> "Content-Type");
>>>>
>>>> It starts working and the gadget renders. Cool. But then the first
>>> makeRequest
>>>> from a gadget seems to be having difficulty.
>>>>
>>>> doug
>>>>
>>>>
>>>
>>>
>>
>
>
Re: [VOTE] Apache Shindig release 2.5.0-beta1
+1 (tested with our project and all is well) On 3/26/12 2:25 PM, "Henry Saputra" wrote: > Hi All, > > Paul Lindner has prepared a release candidate for Shindig 2.5.0-beta1. > > Staging repo: > https://repository.apache.org/content/repositories/orgapacheshindig-114/ > > SVN tag: > http://svn.apache.org/repos/asf/shindig/tags/shindig-project-2.5.0-beta1/ > > Keys: > http://svn.apache.org/repos/asf/shindig/tags/shindig-project-2.5.0-beta1/KEYS > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > Thanks, > > > Henry >
Re: Shindig running on different domain than container REVISITED
One other thing (if it helps). I see gadgets that don't do makeRequest fail
as follows:
Unsafe JavaScript attempt to access frame with URL
http://localhost:9090/opensocial-demo/testcontainer/ from frame with URL
http://localhost:8080/opensocial/gadgets/ifr?url=http%3A%2F%2Fhosting.gmodul
es.com%2Fig%2Fgadgets%2Ffile%2F112581010116074801021%2Fhamster.xml&container
=default&view=default&lang=%25lang%25&country=%25country%25&debug=0&nocache=
0&sanitize=%25sanitize%25&v=d699982ddc921667a106a76c22bc8e22&testmode=0&pare
nt=http%3A%2F%2Flocalhost%3A9090&mid=0#up_hamsterName=%25up_hamsterName%25&u
p_bgColor=%25up_bgColor%25&up_bodyColor=%25up_bodyColor%25&up_earColor=%25up
_earColor%25&up_snoutColor=%25up_snoutColor%25&up_eyeColor=%25up_eyeColor%25
&up_feetColor=%25up_feetColor%25&up_tailColor=%25up_tailColor%25&up_waterCol
or=%25up_waterColor%25&up_foodColor=%25up_foodColor%25&up_wheelColor=%25up_w
heelColor%25&up_wheelOuterColor=%25up_wheelOuterColor%25&up_wheelCenterColor
=%25up_wheelCenterColor%25&up_wheelSpokeColor=%25up_wheelSpokeColor%25.
Domains, protocols and ports must match.
So it's obvious I'm gonna have lots of issues getting this working. Is
cross-domain support on the roadmap anywhere? I can try to tackle this but
if it's on someone's roadmap I'll live with the proxy solution in the
meantime.
doug
On 3/26/12 4:38 PM, "daviesd" wrote:
> Ok, one step forward. If I add
>
> servletResponse.addHeader("Access-Control-Allow-Headers", "Content-Type");
>
> It starts working and the gadget renders. Cool. But then the first makeRequest
> from a gadget seems to be having difficulty.
>
> doug
>
>
Re: Shindig running on different domain than container REVISITED
Ok, one step forward. If I add
servletResponse.addHeader("Access-Control-Allow-Headers", "Content-Type");
It starts working and the gadget renders. Cool. But then the first
makeRequest from a gadget seems to be having difficulty.
doug
On 3/26/12 3:59 PM, "daviesd" wrote:
> Started looking at this. I'm a little unclear what I'm suppose to do if
> JsonRpcServlet receives an OPTIONS request. Right now I was just trying the
> following (after allowing OPTIONS to pass-thru) right after the setCORSheader:
>
> if ("OPTIONS".equals(method)) {
>
> servletResponse.addHeader("Access-Control-Allow-Origin", "*");
> servletResponse.addHeader("Access-Control-Max-Age", "3600");
> servletResponse.addHeader("Access-Control-Allow-Methods", "POST, GET,
> OPTIONS");
> return;
> }
>
> The pre-flight request now succeeds but I don't see any further requests from
> the javascript. Probably my misunderstanding of CORS and XHR. Any
> suggestions on how to best implement this? Or perhaps I'm not gonna get off
> easy with just a few lines of code. :)
>
> doug
>
>
> On 3/22/12 5:19 PM, "daviesd" wrote:
>
>> Again... Thanks Stanton for the quick response. Ok, I'll probably spend a
>> few
>> days with this next week and see what I can do. I know nothing about CORS,
>> but I'll start reading up on it.
>>
>> doug
>>
>>
>> On 3/22/12 5:13 PM, "Stanton Sievers" wrote:
>>
>>> Hi Doug,
>>>
>>> That matches my findings as well. I've not heard of anyone running the
>>> container page and shindig server on different domains without having to
>>> use a proxy on the container page's domain.
>>>
>>>
>>> I'm sure it can be done it just doesn't appear to work with Shindig out
>>> of the box. I think more would have to be done to implement CORS for the
>>> JsonRpcServlet.
>>>
>>> Regards,
>>> -Stanton
>>>
>>>
>>>
>>> From: daviesd
>>> To: ,
>>> Date: 03/22/2012 17:08
>>> Subject:Re: Shindig running on different domain than container
>>> REVISITED
>>>
>>>
>>>
>>> Hi Stanton,
>>>
>>> So is your earlier statement about things working just fine running the
>>> container page and shindig on different domains still true? We are
>>> running
>>> a proxy just like you are (actually in production it's a load balancer
>>> rule). I'd like to know if anyone has this working out of the box without
>>> a
>>> proxy and just the API_HOST and API_PATH config. Hopefully someone can
>>> respond.
>>>
>>> Mike started digging into this today and I'll continue next week (I'm in
>>> class this week), but I think his initial finding is that JsonRpcServlet
>>> is
>>> rejecting anything that isn't POST or GET (thus rejecting OPTIONS).
>>>
>>> Thanks for the help.
>>>
>>> doug
>>>
>>>
>>> On 3/22/12 11:30 AM, "Stanton Sievers" wrote:
>>>
>>>> Hi Mike,
>>>>
>>>> I'm not sure even setting the headers would work (although I haven't
>>> tried
>>>> this in a while). My recollection is that part of CORS is that an
>>> OPTIONS
>>>> request is sent to Shindig's rpc endpoint as part of the "pre-flight"
>>>> step. The rpc servlet doesn't support OPTIONS and will return a 405.
>>> This
>>>> is something we could and probably should look at fixing in Shindig but
>>> no
>>>> one has taken the time to do so so far as I know. Again, it's been a
>>>> while since I've investigated this so things may have changed.
>>>>
>>>> The alternative, and what I've personally done, is have a proxy on the
>>>> container page's domain that can proxy the /rpc calls to Shindig. That
>>>> works just fine. You simply setup your API_HOST and API_PATH to utilize
>>>> the proxy url.
>>>>
>>>> Hope that helps.
>>>>
>>>> -Stanton
>>>>
>>>>
>>>>
>>>> From: Michael Matthews
>>>> To: , Stanton Sievers/Westford/IBM@Lotus,
>>>> Cc: Douglas Davies
>>>> Date:
Re: Shindig running on different domain than container REVISITED
Started looking at this. I'm a little unclear what I'm suppose to do if
JsonRpcServlet receives an OPTIONS request. Right now I was just trying the
following (after allowing OPTIONS to pass-thru) right after the
setCORSheader:
if ("OPTIONS".equals(method)) {
servletResponse.addHeader("Access-Control-Allow-Origin", "*");
servletResponse.addHeader("Access-Control-Max-Age", "3600");
servletResponse.addHeader("Access-Control-Allow-Methods", "POST,
GET, OPTIONS");
return;
}
The pre-flight request now succeeds but I don't see any further requests
from the javascript. Probably my misunderstanding of CORS and XHR. Any
suggestions on how to best implement this? Or perhaps I'm not gonna get off
easy with just a few lines of code. :)
doug
On 3/22/12 5:19 PM, "daviesd" wrote:
> Again... Thanks Stanton for the quick response. Ok, I'll probably spend a few
> days with this next week and see what I can do. I know nothing about CORS,
> but I'll start reading up on it.
>
> doug
>
>
> On 3/22/12 5:13 PM, "Stanton Sievers" wrote:
>
>> Hi Doug,
>>
>> That matches my findings as well. I've not heard of anyone running the
>> container page and shindig server on different domains without having to
>> use a proxy on the container page's domain.
>>
>>
>> I'm sure it can be done it just doesn't appear to work with Shindig out
>> of the box. I think more would have to be done to implement CORS for the
>> JsonRpcServlet.
>>
>> Regards,
>> -Stanton
>>
>>
>>
>> From: daviesd
>> To: ,
>> Date: 03/22/2012 17:08
>> Subject:Re: Shindig running on different domain than container
>> REVISITED
>>
>>
>>
>> Hi Stanton,
>>
>> So is your earlier statement about things working just fine running the
>> container page and shindig on different domains still true? We are
>> running
>> a proxy just like you are (actually in production it's a load balancer
>> rule). I'd like to know if anyone has this working out of the box without
>> a
>> proxy and just the API_HOST and API_PATH config. Hopefully someone can
>> respond.
>>
>> Mike started digging into this today and I'll continue next week (I'm in
>> class this week), but I think his initial finding is that JsonRpcServlet
>> is
>> rejecting anything that isn't POST or GET (thus rejecting OPTIONS).
>>
>> Thanks for the help.
>>
>> doug
>>
>>
>> On 3/22/12 11:30 AM, "Stanton Sievers" wrote:
>>
>>> Hi Mike,
>>>
>>> I'm not sure even setting the headers would work (although I haven't
>> tried
>>> this in a while). My recollection is that part of CORS is that an
>> OPTIONS
>>> request is sent to Shindig's rpc endpoint as part of the "pre-flight"
>>> step. The rpc servlet doesn't support OPTIONS and will return a 405.
>> This
>>> is something we could and probably should look at fixing in Shindig but
>> no
>>> one has taken the time to do so so far as I know. Again, it's been a
>>> while since I've investigated this so things may have changed.
>>>
>>> The alternative, and what I've personally done, is have a proxy on the
>>> container page's domain that can proxy the /rpc calls to Shindig. That
>>> works just fine. You simply setup your API_HOST and API_PATH to utilize
>>> the proxy url.
>>>
>>> Hope that helps.
>>>
>>> -Stanton
>>>
>>>
>>>
>>> From: Michael Matthews
>>> To: , Stanton Sievers/Westford/IBM@Lotus,
>>> Cc: Douglas Davies
>>> Date: 03/22/2012 11:17
>>> Subject:Re: Shindig running on different domain than container
>>> REVISITED
>>>
>>>
>>>
>>> First of all, thanks for the quick response to this.
>>>
>>> I've modified our UI to pass the API_HOST and API_PATH as mentioned
>> below.
>>> I
>>> know see an HTTP OPTIONS request failing. From the browser's console:
>>>
>>> XMLHttpRequest cannot load
>>>
>> http://worldkat.dev.oclc.org/opensocial/rpc?st=oclc%3AilCK3wGsfqUWqIct7oHK19
>>
>>>
>>>
>> RHViz9iHzb9ON-FGx5SeW_dk80zHiMOislNdLbszrLT-d6tjzTJw97nDIx92xDoCfQ3LW-JuWc8w
>>>
>> k4HZrHckNYnMG9P1wiZt
Re: Shindig running on different domain than container REVISITED
Again... Thanks Stanton for the quick response. Ok, I'll probably spend a few days with this next week and see what I can do. I know nothing about CORS, but I'll start reading up on it. doug On 3/22/12 5:13 PM, "Stanton Sievers" wrote: > Hi Doug, > > That matches my findings as well. I've not heard of anyone running the > container page and shindig server on different domains without having to > use a proxy on the container page's domain. > > > I'm sure it can be done it just doesn't appear to work with Shindig out > of the box. I think more would have to be done to implement CORS for the > JsonRpcServlet. > > Regards, > -Stanton > > > > From: daviesd > To: , > Date: 03/22/2012 17:08 > Subject:Re: Shindig running on different domain than container > REVISITED > > > > Hi Stanton, > > So is your earlier statement about things working just fine running the > container page and shindig on different domains still true? We are > running > a proxy just like you are (actually in production it's a load balancer > rule). I'd like to know if anyone has this working out of the box without > a > proxy and just the API_HOST and API_PATH config. Hopefully someone can > respond. > > Mike started digging into this today and I'll continue next week (I'm in > class this week), but I think his initial finding is that JsonRpcServlet > is > rejecting anything that isn't POST or GET (thus rejecting OPTIONS). > > Thanks for the help. > > doug > > > On 3/22/12 11:30 AM, "Stanton Sievers" wrote: > >> Hi Mike, >> >> I'm not sure even setting the headers would work (although I haven't > tried >> this in a while). My recollection is that part of CORS is that an > OPTIONS >> request is sent to Shindig's rpc endpoint as part of the "pre-flight" >> step. The rpc servlet doesn't support OPTIONS and will return a 405. > This >> is something we could and probably should look at fixing in Shindig but > no >> one has taken the time to do so so far as I know. Again, it's been a >> while since I've investigated this so things may have changed. >> >> The alternative, and what I've personally done, is have a proxy on the >> container page's domain that can proxy the /rpc calls to Shindig. That >> works just fine. You simply setup your API_HOST and API_PATH to utilize >> the proxy url. >> >> Hope that helps. >> >> -Stanton >> >> >> >> From: Michael Matthews >> To: , Stanton Sievers/Westford/IBM@Lotus, >> Cc: Douglas Davies >> Date: 03/22/2012 11:17 >> Subject:Re: Shindig running on different domain than container >> REVISITED >> >> >> >> First of all, thanks for the quick response to this. >> >> I've modified our UI to pass the API_HOST and API_PATH as mentioned > below. >> I >> know see an HTTP OPTIONS request failing. From the browser's console: >> >> XMLHttpRequest cannot load >> > http://worldkat.dev.oclc.org/opensocial/rpc?st=oclc%3AilCK3wGsfqUWqIct7oHK19 > >> >> > RHViz9iHzb9ON-FGx5SeW_dk80zHiMOislNdLbszrLT-d6tjzTJw97nDIx92xDoCfQ3LW-JuWc8w >> > k4HZrHckNYnMG9P1wiZtInHqq9-VqET8W-fusiWAAaazBul0ARi0RI2K6cJINxRZ7-7yhExX_Gny >> > IW4PumEVYs9f6-6iRR6WsUEoKGATW13PtUM3NmDNZOhFI2E19l4yTlLibK2r68IN7LY_Lx6QJ6kl >> > PN7a_cIe5IYBRFV-SAvcexnCfnnlp5gjbs9unXeGSDIedJesYi8daX0b4-DmUVFUMexi7e3txdCY >> > inHExk7XYfbAgjc8Qpi8YEngUiTJzI2E5A02_Eb9B8kf5KEeaR4yKehI3DTKY6JTMCO6dQupqzu7 >> > oHDS2n7H3SgCIjpfzBycsrhiioiNJfOInQ0hd3FJ3g9U4geJzz_5mPli-vXB3xL6WaDL5wtXHYYT >> GGVW0i_tKZKGTsjpFwLmD9gmytlt47pMEPW8zTWg. Origin http://localhost:8080 >> <http://localhost/> is not allowed by Access-Control-Allow-Origin. >> >> The OPTIONS request has the following headers set: >> >> Access-Control-Request-Method: POST >> Origin: http://localhost:8080 >> Access-Control-Request-Headers: Origin, Content-Type >> >> I found the post >> http://www.mail-archive.com/dev@shindig.apache.org/msg03230.html which >> suggests additional configuration is required to set this in the PHP >> version >> of Shindig. >> >> >> In the java version of shindig, is there additional configuration > required >> to set a Access-Control-Allow-Origin header on the response to allow the >> cross-site request? >> >> Thanks >> Mike >> >> >> On 3/22/12 7:23 AM, "Stant
Re: Shindig running on different domain than container REVISITED
Hi Stanton, So is your earlier statement about things working just fine running the container page and shindig on different domains still true? We are running a proxy just like you are (actually in production it's a load balancer rule). I'd like to know if anyone has this working out of the box without a proxy and just the API_HOST and API_PATH config. Hopefully someone can respond. Mike started digging into this today and I'll continue next week (I'm in class this week), but I think his initial finding is that JsonRpcServlet is rejecting anything that isn't POST or GET (thus rejecting OPTIONS). Thanks for the help. doug On 3/22/12 11:30 AM, "Stanton Sievers" wrote: > Hi Mike, > > I'm not sure even setting the headers would work (although I haven't tried > this in a while). My recollection is that part of CORS is that an OPTIONS > request is sent to Shindig's rpc endpoint as part of the "pre-flight" > step. The rpc servlet doesn't support OPTIONS and will return a 405. This > is something we could and probably should look at fixing in Shindig but no > one has taken the time to do so so far as I know. Again, it's been a > while since I've investigated this so things may have changed. > > The alternative, and what I've personally done, is have a proxy on the > container page's domain that can proxy the /rpc calls to Shindig. That > works just fine. You simply setup your API_HOST and API_PATH to utilize > the proxy url. > > Hope that helps. > > -Stanton > > > > From: Michael Matthews > To: , Stanton Sievers/Westford/IBM@Lotus, > Cc: Douglas Davies > Date: 03/22/2012 11:17 > Subject:Re: Shindig running on different domain than container > REVISITED > > > > First of all, thanks for the quick response to this. > > I've modified our UI to pass the API_HOST and API_PATH as mentioned below. > I > know see an HTTP OPTIONS request failing. From the browser's console: > > XMLHttpRequest cannot load > http://worldkat.dev.oclc.org/opensocial/rpc?st=oclc%3AilCK3wGsfqUWqIct7oHK19 > > RHViz9iHzb9ON-FGx5SeW_dk80zHiMOislNdLbszrLT-d6tjzTJw97nDIx92xDoCfQ3LW-JuWc8w > k4HZrHckNYnMG9P1wiZtInHqq9-VqET8W-fusiWAAaazBul0ARi0RI2K6cJINxRZ7-7yhExX_Gny > IW4PumEVYs9f6-6iRR6WsUEoKGATW13PtUM3NmDNZOhFI2E19l4yTlLibK2r68IN7LY_Lx6QJ6kl > PN7a_cIe5IYBRFV-SAvcexnCfnnlp5gjbs9unXeGSDIedJesYi8daX0b4-DmUVFUMexi7e3txdCY > inHExk7XYfbAgjc8Qpi8YEngUiTJzI2E5A02_Eb9B8kf5KEeaR4yKehI3DTKY6JTMCO6dQupqzu7 > oHDS2n7H3SgCIjpfzBycsrhiioiNJfOInQ0hd3FJ3g9U4geJzz_5mPli-vXB3xL6WaDL5wtXHYYT > GGVW0i_tKZKGTsjpFwLmD9gmytlt47pMEPW8zTWg. Origin http://localhost:8080 > <http://localhost/> is not allowed by Access-Control-Allow-Origin. > > The OPTIONS request has the following headers set: > > Access-Control-Request-Method: POST > Origin: http://localhost:8080 > Access-Control-Request-Headers: Origin, Content-Type > > I found the post > http://www.mail-archive.com/dev@shindig.apache.org/msg03230.html which > suggests additional configuration is required to set this in the PHP > version > of Shindig. > > > In the java version of shindig, is there additional configuration required > to set a Access-Control-Allow-Origin header on the response to allow the > cross-site request? > > Thanks > Mike > > > On 3/22/12 7:23 AM, "Stanton Sievers" wrote: > >> From what I understand rpc_relay setup is only needed if you are using > the >> ifpc transport for rpc. You can force this by setting useLegacyProtocol >> in your container config but why you would want to do that I do not > know. >> With modern browsers (html5) Shindig makes use of window.postMessage >> (wpm) to do rpc and you don't have to worry about the relay setup. In >> general the fallback for non-html 5 browsers is using a flash technique > if >> possible. If you're interested in the way the rpc transport is chosen, >> you can check out rpc.js#getTransport() for more info. >> >> -Stanton >> >> >> >> From: "Davies,Douglas" >> To: , >> Date: 03/21/2012 20:28 >> Subject:Re: Shindig running on different domain than container >> REVISITED >> >> >> >> Thanks Stanton. So no rpc_relay setup etc.? Seems last time I did this > I >> ran into that. >> >> Doug >> >> Sent from my iPhone >> >> On Mar 21, 2012, at 3:43 PM, "Stanton Sievers" >> wrote: >> >>> Hi Doug, >>> >>> Yes, things work just fine running the container page and shindig on >>> dif
Re: Review Request: Fix for SHINDIG-1736
Thanks for the "newbie" info. :) On 3/21/12 2:34 PM, "Ciancetta, Jesse E." wrote: > And you also need to be sure to select the radio option for: > > "Grant license to ASF for inclusion in ASF works" > > when uploading the patch -- otherwise we can't legally apply it. It doesn¹t > look like you did that when attaching the current patch to the JIRA ticket. > > Sorry for the extra hoops to jump through... > > --Jesse > >> -Original Message- >> From: Henry Saputra [mailto:henry.sapu...@gmail.com] >> Sent: Wednesday, March 21, 2012 1:31 PM >> To: dev@shindig.apache.org >> Subject: Re: Review Request: Fix for SHINDIG-1736 >> >> Dont want to be party pooper but Doug could you attach the patch to >> the JIRA associated with this review? >> >> - Henry >> >> On Wed, Mar 21, 2012 at 6:38 AM, Ryan J Baxter >> wrote: >>> I can commit it. I was also waiting for Paul to take a look at it. If he >>> doesn't get to it by the end of the day I will commit it. >>> >>> -Ryan >>> >>> >>> >>> >>> From: daviesd >>> To: , Paul Lindner , >>> Cc: Ryan Baxter >>> Date: 03/20/2012 11:04 PM >>> Subject: Re: Review Request: Fix for SHINDIG-1736 >>> >>> >>> >>> Thanks Ryan. How do I go about getting a committer to commit this? I was >>> hoping Paul would review before then, but I'd love to see this get in >>> before >>> the next 2.5 beta. >>> >>> doug >>> >>> >>> On 3/19/12 9:09 AM, "Ryan Baxter" wrote: >>> >>>> >>>> --- >>>> This is an automatically generated e-mail. To reply, visit: >>>> https://reviews.apache.org/r/4366/#review6070 >>>> --- >>>> >>>> Ship it! >>>> >>>> >>>> LGTM >>>> >>>> - Ryan >>>> >>>> >>>> On 2012-03-15 17:47:31, Doug Davies wrote: >>>>> >>>>> --- >>>>> This is an automatically generated e-mail. To reply, visit: >>>>> https://reviews.apache.org/r/4366/ >>>>> --- >>>>> >>>>> (Updated 2012-03-15 17:47:31) >>>>> >>>>> >>>>> Review request for shindig and Paul Lindner. >>>>> >>>>> >>>>> Summary >>>>> --- >>>>> >>>>> This is a fix for SHINDIG-1736. Currently the recently updated >>> JsonUtil >>>>> blows up if the class it is trying to parse has synthetic methods >>> generated >>>>> by the compiler for handling runtime generics substitution. It now >>> checks to >>>>> make sure the method is not synthetic. I've included a unit test that >>> tests >>>>> this scenario. >>>>> >>>>> >>>>> This addresses bug SHINDIG-1736. >>>>> https://issues.apache.org/jira/browse/SHINDIG-1736 >>>>> >>>>> >>>>> Diffs >>>>> - >>>>> >>>>> >>> >> /trunk/java/common/src/main/java/org/apache/shindig/common/JsonUtil.ja >> va >>>>> 1299867 >>>>> >>>>> >>> >> /trunk/java/common/src/test/java/org/apache/shindig/common/JsonUtilTes >> t.java >>>>> 1299867 >>>>> >>>>> Diff: https://reviews.apache.org/r/4366/diff >>>>> >>>>> >>>>> Testing >>>>> --- >>>>> >>>>> unit test provided >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Doug >>>>> >>>>> >>>> >>> >>> >>>
Shindig running on different domain than container REVISITED
About a year ago there was a discussion about shindig running on a different domain than the container. http://permalink.gmane.org/gmane.comp.web.shindig.devel/6824 Up till this point we have been running our shindig servers and our container webapps on the same domain. We¹d like to move away from this. Is this possible with shindig 2.5.0? Have there been changes since this discussion? If so, is there documentation on what configuration needs to happen to get this to work? Thanks, Doug
Re: [REQUEST] Beta Release for 2.5
+1 for a 2.5 beta release. On 3/20/12 4:35 PM, "Franklin, Matthew B." wrote: > Once the patch Ate submitted for the LICENSE & NOTICE files is applied, I > would like to request a Beta release for 2.5. There are a couple of features > we would really like to use in Rave; but are unable to at the moment as our > releases cannot depend on snapshots. > > If you decide to cut a beta release, any idea what you would call it? 2.5 > Beta 1? > > Thanks in advance, > Matt >
Re: Review Request: Fix for SHINDIG-1736
Thanks Ryan. How do I go about getting a committer to commit this? I was hoping Paul would review before then, but I'd love to see this get in before the next 2.5 beta. doug On 3/19/12 9:09 AM, "Ryan Baxter" wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/4366/#review6070 > --- > > Ship it! > > > LGTM > > - Ryan > > > On 2012-03-15 17:47:31, Doug Davies wrote: >> >> --- >> This is an automatically generated e-mail. To reply, visit: >> https://reviews.apache.org/r/4366/ >> --- >> >> (Updated 2012-03-15 17:47:31) >> >> >> Review request for shindig and Paul Lindner. >> >> >> Summary >> --- >> >> This is a fix for SHINDIG-1736. Currently the recently updated JsonUtil >> blows up if the class it is trying to parse has synthetic methods generated >> by the compiler for handling runtime generics substitution. It now checks to >> make sure the method is not synthetic. I've included a unit test that tests >> this scenario. >> >> >> This addresses bug SHINDIG-1736. >> https://issues.apache.org/jira/browse/SHINDIG-1736 >> >> >> Diffs >> - >> >> /trunk/java/common/src/main/java/org/apache/shindig/common/JsonUtil.java >> 1299867 >> >> /trunk/java/common/src/test/java/org/apache/shindig/common/JsonUtilTest.java >> 1299867 >> >> Diff: https://reviews.apache.org/r/4366/diff >> >> >> Testing >> --- >> >> unit test provided >> >> >> Thanks, >> >> Doug >> >> >
Re: requestNavigateTo and set_title are unknown RPC services if I don't include shindig-container feature.
You need to implement those since every container might handle it differently. doug On 3/18/12 10:26 PM, "Jian L Hu" wrote: > > > Hi All, > > views and settitle features have dependency to services like > requestNavigateTo and set_title. > However common container don't register these RPC services as the > shindig-container did. > shindig-container and container are mutually exclusive features. How can I > get these RPC services if container feature is loaded? > > JIRA: https://issues.apache.org/jira/browse/SHINDIG-1734 > > Thanks for your help. > > Best regards > > Jian Hu(胡健) > > Telephone: 86-10-82453924 > E-mail : hujia...@cn.ibm.com >
Re: Problem with latest shindig
I¹ve created a unit test to verify this. It looks as follows:
public abstract class ObjectId {
private final IdType value;
protected ObjectId() {
value = null;
}
protected final IdType getIdValue() {
return value;
}
public abstract IdType getValue();
}
public class ApplicationId extends ObjectId {
@Override
public Long getValue() {
return getIdValue();
}
}
@Test
public void duplicateMethodPojo() throws Exception {
ApplicationId pojo = new ApplicationId();
Map methods = JsonUtil.getGetters(pojo);
}
I¹m looking into submitting a patch to JsonUtil to fix this (along with
submitting this test case).
If I¹m only going to put the method into the map once, does anyone know what
method should be selected? I think the method modifiers will give me enough
details to determine this. I imagine the interface or abstract ones can be
thrown out. Ideas?
doug
On 3/14/12 10:39 AM, "daviesd" wrote:
> Paul,
>
> I¹m trying to track down this LocalCache problem that was introduced on commit
> r1290973. What I¹ve noticed is that it fails when it thinks two methods have
> the same signature. For example I see this list of methods:
Re: Problem with latest shindig
Paul, I¹m trying to track down this LocalCache problem that was introduced on commit r1290973. What I¹ve noticed is that it fails when it thinks two methods have the same signature. For example I see this list of methods: [ public static org.oclc.platform.opensocial.spi.ApplicationId org.oclc.platform.opensocial.spi.ApplicationId.valueOf(java.lang.String), public java.lang.Long org.oclc.platform.opensocial.spi.ApplicationId.getValue(), public java.io.Serializable org.oclc.platform.opensocial.spi.ApplicationId.getValue(),public boolean org.oclc.platform.opensocial.spi.ObjectId.equals(java.lang.Object), public java.lang.String org.oclc.platform.opensocial.spi.ObjectId.toString(), public int org.oclc.platform.opensocial.spi.ObjectId.hashCode(), public final void java.lang.Object.wait() throws java.lang.InterruptedException, public final native void java.lang.Object.wait(long) throws java.lang.InterruptedException, public final void java.lang.Object.wait(long,int) throws java.lang.InterruptedException, public final native java.lang.Class java.lang.Object.getClass(), public final native void java.lang.Object.notify(), public final native void java.lang.Object.notifyAll() ] When JsonUtil¹s LoadingCache processes it it end up with a of methods like this [ value=public java.lang.Long org.oclc.platform.opensocial.spi.ApplicationId.getValue(), value=public java.io.Serializable org.oclc.platform.opensocial.spi.ApplicationId.getValue() ] When methods.build() is called it blows up with java.lang.IllegalArgumentException: duplicate key: value If I rollback JsonUtil to the version before this commit I no longer have the issue. Ideas? doug On 3/5/12 5:33 PM, "daviesd" wrote: > I just got back from vacation and pulled down today¹s 2.5.0. Some of my unit > tests that derive from AbstractLargeRestfulTests are failing deep in the > bowels of LocalCache.java. Specifically I get a > > java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: > duplicate key: value > > exception when recordMisses is being called. I know there was a recent > upgrade to guava 11.0.1. Wondering if this might be affecting this. Does > this make sense to anyone? If so, let me know. > > Doug
Features css
Is there a way for a feature to include css? I noticed minimessage does this, but messily through container.js. I¹d like to have a feature.css that sits along side the feature.xml and feature.js. Any ideas are appreciated. Doug
Re: SHINDIG-1719 - UnsupportedOperationException
Yep. Works. Thanks! On 3/7/12 2:22 PM, "Henry Saputra" wrote: > Done, could you try the fix by pulling from trunk? > > - Henry > > On Wed, Mar 7, 2012 at 10:45 AM, daviesd wrote: >> Thank you. I've been banging my head on this all morning. ?Now if I can get >> Paul to look at the guava collections stuff I might be good to go. :) >> >> doug >> >> >> On 3/7/12 1:31 PM, "Henry Saputra" wrote: >> >>> I think I know whats the problem, I remove the check for the >>> UnsupportedOperationException in the >>> BlobCrypterSecurityTokenCodec.fromToken to get activeUrl. >>> >>> The gadget handler code use the "delegator" to mock the security token >>> instance and miss setting the active URL. >>> >>> Hence when the call to token.getActiveUrl it chokes. >>> >>> Honestly I think the whole delegator stuff is not working well. ?I >>> will put up the patch to fix this. >>> >>> - Henry >>> >>> On Wed, Mar 7, 2012 at 8:11 AM, daviesd wrote: >>>> Henry, >>>> >>>> I changed our security token implementation to extend AbstractSecurityToken >>>> instead of just implementing SecurityToken. ?No difference. ?As I said, if >>>> I >>>> use a non-encrypted security token I don't see this error. ?I'm fighting a >>>> couple of issues (including the one I mentioned to Paul earlier concerning >>>> the google collection changes he made). ?Getting a little frustrating >>>> getting things back in synch. >>>> >>>> doug >>>> >>>> >>>> On 3/6/12 4:41 PM, "Henry Saputra" wrote: >>>> >>>>> Do you extend the OurDefaultSecurityTokenCodec from AbstractSecurityToken? >>>>> >>>>> If you do then you dont need to do anything I think >>>>> >>>>> - Henry >>>>> >>>>> On Tue, Mar 6, 2012 at 1:03 PM, daviesd wrote: >>>>>> Ya it's the difference between insecure and secure. ?If I use insecure >>>>>> tokens it works. ?If I switch to secure (our default) it gets this >>>>>> exception >>>>>> when encoding the token. >>>>>> >>>>>> doug >>>>>> >>>>>> >>>>>> On 3/6/12 3:29 PM, "Henry Saputra" wrote: >>>>>> >>>>>>> Hey Doug, >>>>>>> >>>>>>> Sorry about the trouble. >>>>>>> >>>>>>> How do you reproduce this? >>>>>>> >>>>>>> - Henry >>>>>>> >>>>>>> On Tue, Mar 6, 2012 at 12:13 PM, daviesd wrote: >>>>>>>> Henry, >>>>>>>> >>>>>>>> I¹m having issues with the fix for SHINDIG-1719. ? The stacktrace looks >>>>>>>> as >>>>>>>> follows: >>>>>>>> >>>>>>>> Mar 6, 2012 3:04:20 PM >>>>>>>> org.apache.shindig.gadgets.servlet.GadgetsHandlerService >>>>>>>> createErrorResponse >>>>>>>> WARNING: Error handling request: >>>>>>>> java.lang.UnsupportedOperationException: Unsupported function: >>>>>>>> getActiveUrl >>>>>>>> ? ?at >>>>>>>> >>>> org.apache.shindig.protocol.conversion.BeanDelegator$DelegateInvocationHand >>>> >> >>>>>> >>>> l >>>>>>>> er.invoke(BeanDelegator.java:257) >>>>>>>> ? ?at $Proxy90.getActiveUrl(Unknown Source) >>>>>>>> ? ?at >>>>>>>> >>>> org.apache.shindig.auth.BlobCrypterSecurityToken.fromToken(BlobCrypterSecur >>>> >> >>>>>> >>>> i >>>>>>>> tyToken.java:74) >>>>>>>> ? ?at >>>>>>>> >>>> org.apache.shindig.auth.BlobCrypterSecurityTokenCodec.encodeToken(BlobCrypt >>>> >> >>>>>> >>>> e >>>>>>>> rSecurityTokenCodec.java:171) >>>>>>>> >>>>>>>> Ideas? >>>>>>>> >>>>>>>> Doug >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> >
Re: SHINDIG-1719 - UnsupportedOperationException
Thank you. I've been banging my head on this all morning. Now if I can get Paul to look at the guava collections stuff I might be good to go. :) doug On 3/7/12 1:31 PM, "Henry Saputra" wrote: > I think I know whats the problem, I remove the check for the > UnsupportedOperationException in the > BlobCrypterSecurityTokenCodec.fromToken to get activeUrl. > > The gadget handler code use the "delegator" to mock the security token > instance and miss setting the active URL. > > Hence when the call to token.getActiveUrl it chokes. > > Honestly I think the whole delegator stuff is not working well. I > will put up the patch to fix this. > > - Henry > > On Wed, Mar 7, 2012 at 8:11 AM, daviesd wrote: >> Henry, >> >> I changed our security token implementation to extend AbstractSecurityToken >> instead of just implementing SecurityToken. ?No difference. ?As I said, if I >> use a non-encrypted security token I don't see this error. ?I'm fighting a >> couple of issues (including the one I mentioned to Paul earlier concerning >> the google collection changes he made). ?Getting a little frustrating >> getting things back in synch. >> >> doug >> >> >> On 3/6/12 4:41 PM, "Henry Saputra" wrote: >> >>> Do you extend the OurDefaultSecurityTokenCodec from AbstractSecurityToken? >>> >>> If you do then you dont need to do anything I think >>> >>> - Henry >>> >>> On Tue, Mar 6, 2012 at 1:03 PM, daviesd wrote: >>>> Ya it's the difference between insecure and secure. ?If I use insecure >>>> tokens it works. ?If I switch to secure (our default) it gets this >>>> exception >>>> when encoding the token. >>>> >>>> doug >>>> >>>> >>>> On 3/6/12 3:29 PM, "Henry Saputra" wrote: >>>> >>>>> Hey Doug, >>>>> >>>>> Sorry about the trouble. >>>>> >>>>> How do you reproduce this? >>>>> >>>>> - Henry >>>>> >>>>> On Tue, Mar 6, 2012 at 12:13 PM, daviesd wrote: >>>>>> Henry, >>>>>> >>>>>> I¹m having issues with the fix for SHINDIG-1719. ? The stacktrace looks >>>>>> as >>>>>> follows: >>>>>> >>>>>> Mar 6, 2012 3:04:20 PM >>>>>> org.apache.shindig.gadgets.servlet.GadgetsHandlerService >>>>>> createErrorResponse >>>>>> WARNING: Error handling request: >>>>>> java.lang.UnsupportedOperationException: Unsupported function: >>>>>> getActiveUrl >>>>>> ? ?at >>>>>> >> org.apache.shindig.protocol.conversion.BeanDelegator$DelegateInvocationHand>> >> >> >> l >>>>>> er.invoke(BeanDelegator.java:257) >>>>>> ? ?at $Proxy90.getActiveUrl(Unknown Source) >>>>>> ? ?at >>>>>> >> org.apache.shindig.auth.BlobCrypterSecurityToken.fromToken(BlobCrypterSecur>> >> >> >> i >>>>>> tyToken.java:74) >>>>>> ? ?at >>>>>> >> org.apache.shindig.auth.BlobCrypterSecurityTokenCodec.encodeToken(BlobCrypt>> >> >> >> e >>>>>> rSecurityTokenCodec.java:171) >>>>>> >>>>>> Ideas? >>>>>> >>>>>> Doug >>>>> >>>> >>>> >>> >> >> >
Re: SHINDIG-1719 - UnsupportedOperationException
Henry, I changed our security token implementation to extend AbstractSecurityToken instead of just implementing SecurityToken. No difference. As I said, if I use a non-encrypted security token I don't see this error. I'm fighting a couple of issues (including the one I mentioned to Paul earlier concerning the google collection changes he made). Getting a little frustrating getting things back in synch. doug On 3/6/12 4:41 PM, "Henry Saputra" wrote: > Do you extend the OurDefaultSecurityTokenCodec from AbstractSecurityToken? > > If you do then you dont need to do anything I think > > - Henry > > On Tue, Mar 6, 2012 at 1:03 PM, daviesd wrote: >> Ya it's the difference between insecure and secure. ?If I use insecure >> tokens it works. ?If I switch to secure (our default) it gets this exception >> when encoding the token. >> >> doug >> >> >> On 3/6/12 3:29 PM, "Henry Saputra" wrote: >> >>> Hey Doug, >>> >>> Sorry about the trouble. >>> >>> How do you reproduce this? >>> >>> - Henry >>> >>> On Tue, Mar 6, 2012 at 12:13 PM, daviesd wrote: >>>> Henry, >>>> >>>> I¹m having issues with the fix for SHINDIG-1719. ? The stacktrace looks as >>>> follows: >>>> >>>> Mar 6, 2012 3:04:20 PM >>>> org.apache.shindig.gadgets.servlet.GadgetsHandlerService >>>> createErrorResponse >>>> WARNING: Error handling request: >>>> java.lang.UnsupportedOperationException: Unsupported function: getActiveUrl >>>> ? ?at >>>> org.apache.shindig.protocol.conversion.BeanDelegator$DelegateInvocationHand>>>> l >>>> er.invoke(BeanDelegator.java:257) >>>> ? ?at $Proxy90.getActiveUrl(Unknown Source) >>>> ? ?at >>>> org.apache.shindig.auth.BlobCrypterSecurityToken.fromToken(BlobCrypterSecur>>>> i >>>> tyToken.java:74) >>>> ? ?at >>>> org.apache.shindig.auth.BlobCrypterSecurityTokenCodec.encodeToken(BlobCrypt>>>> e >>>> rSecurityTokenCodec.java:171) >>>> >>>> Ideas? >>>> >>>> Doug >>> >> >> >
Re: SHINDIG-1719 - UnsupportedOperationException
Ya it's the difference between insecure and secure. If I use insecure tokens it works. If I switch to secure (our default) it gets this exception when encoding the token. doug On 3/6/12 3:29 PM, "Henry Saputra" wrote: > Hey Doug, > > Sorry about the trouble. > > How do you reproduce this? > > - Henry > > On Tue, Mar 6, 2012 at 12:13 PM, daviesd wrote: >> Henry, >> >> I¹m having issues with the fix for SHINDIG-1719. ? The stacktrace looks as >> follows: >> >> Mar 6, 2012 3:04:20 PM >> org.apache.shindig.gadgets.servlet.GadgetsHandlerService createErrorResponse >> WARNING: Error handling request: >> java.lang.UnsupportedOperationException: Unsupported function: getActiveUrl >> ? ?at >> org.apache.shindig.protocol.conversion.BeanDelegator$DelegateInvocationHandl >> er.invoke(BeanDelegator.java:257) >> ? ?at $Proxy90.getActiveUrl(Unknown Source) >> ? ?at >> org.apache.shindig.auth.BlobCrypterSecurityToken.fromToken(BlobCrypterSecuri >> tyToken.java:74) >> ? ?at >> org.apache.shindig.auth.BlobCrypterSecurityTokenCodec.encodeToken(BlobCrypte >> rSecurityTokenCodec.java:171) >> >> Ideas? >> >> Doug >
Re: SHINDIG-1719 - UnsupportedOperationException
I think it's because we have our own implementation of DefaultSecurityTokenCodec that we override with guice. this.bind(SecurityTokenCodec.class).to(OurDefaultSecurityTokenCodec.class); If I change this back to DefaultSecurityTokenCodec things work fine. I don't exactly remember the reason we were overriding it, but it had something to do with reading the config for secure and insecure differently than the default implementation did. doug On 3/6/12 3:29 PM, "Henry Saputra" wrote: > Hey Doug, > > Sorry about the trouble. > > How do you reproduce this? > > - Henry > > On Tue, Mar 6, 2012 at 12:13 PM, daviesd wrote: >> Henry, >> >> I¹m having issues with the fix for SHINDIG-1719. ? The stacktrace looks as >> follows: >> >> Mar 6, 2012 3:04:20 PM >> org.apache.shindig.gadgets.servlet.GadgetsHandlerService createErrorResponse >> WARNING: Error handling request: >> java.lang.UnsupportedOperationException: Unsupported function: getActiveUrl >> ? ?at >> org.apache.shindig.protocol.conversion.BeanDelegator$DelegateInvocationHandl >> er.invoke(BeanDelegator.java:257) >> ? ?at $Proxy90.getActiveUrl(Unknown Source) >> ? ?at >> org.apache.shindig.auth.BlobCrypterSecurityToken.fromToken(BlobCrypterSecuri >> tyToken.java:74) >> ? ?at >> org.apache.shindig.auth.BlobCrypterSecurityTokenCodec.encodeToken(BlobCrypte >> rSecurityTokenCodec.java:171) >> >> Ideas? >> >> Doug >
SHINDIG-1719 - UnsupportedOperationException
Henry, I¹m having issues with the fix for SHINDIG-1719. The stacktrace looks as follows: Mar 6, 2012 3:04:20 PM org.apache.shindig.gadgets.servlet.GadgetsHandlerService createErrorResponse WARNING: Error handling request: java.lang.UnsupportedOperationException: Unsupported function: getActiveUrl at org.apache.shindig.protocol.conversion.BeanDelegator$DelegateInvocationHandl er.invoke(BeanDelegator.java:257) at $Proxy90.getActiveUrl(Unknown Source) at org.apache.shindig.auth.BlobCrypterSecurityToken.fromToken(BlobCrypterSecuri tyToken.java:74) at org.apache.shindig.auth.BlobCrypterSecurityTokenCodec.encodeToken(BlobCrypte rSecurityTokenCodec.java:171) Ideas? Doug
Re: Problem with latest shindig
Paul, I think this has to do with version 1290973 of JsonUtil.java which you made changes to. If I roll this file back to version 950407 my tests work again. Ideas? I¹m banging my head against the wall on this one. doug On 3/5/12 5:33 PM, "daviesd" wrote: > I just got back from vacation and pulled down today¹s 2.5.0. Some of my unit > tests that derive from AbstractLargeRestfulTests are failing deep in the > bowels of LocalCache.java. Specifically I get a > > java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: > duplicate key: value > > exception when recordMisses is being called. I know there was a recent > upgrade to guava 11.0.1. Wondering if this might be affecting this. Does > this make sense to anyone? If so, let me know. > > Doug
Problem with latest shindig
I just got back from vacation and pulled down today¹s 2.5.0. Some of my unit tests that derive from AbstractLargeRestfulTests are failing deep in the bowels of LocalCache.java. Specifically I get a java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: duplicate key: value exception when recordMisses is being called. I know there was a recent upgrade to guava 11.0.1. Wondering if this might be affecting this. Does this make sense to anyone? If so, let me know. Doug
Listening for view change
I¹m working on this user preferences ui. I have the need to listen for a view change request. For example my chrome has a dropdown with all the views supported by the gadget listed as well as a preferences view added (even if the gadget doesn¹t support it). Now I want to know when the preferences option is chosen. I tried a couple of things. 1. setup a onNavigated lifecycle listener. This gets called, but since my gadget doesn¹t have the preferences view it get a siteHolder.view of default. Is there a way to find the originally requested view? 2. I setup a container.config_[osapi.container.ContainerConfig.NAVIGATE_CALLBACK] (like the SET_PREFERENCES, etc.). I must be missing something here, cuz I don¹t seem to be getting called. 3. register a requestNavigateTo rpc function. This gets called, but only when the gadget is requesting navigation, not my container. Ideas on my best approach here? doug
Re: User Prefs Panel Brainstorm
Thanks for all the great feedback. So here¹s what I am thinking... * I create a new container feature called setprefs-ui (or something like that) that displays an edit field for each preference just like Rave or iGoogle does. * My chrome has a way to select EDIT PREFERENCES. If selected it first checks if the gadget supports the PREFRENCES view and if so it navigates to it, otherwise it displays this generic container ui. I noticed iGoogle and Rave both push down the gadget content to display the preferences. I¹m thinking of replacing the view area, displaying my ui, and then when done redisplaying the original view (perhaps hiding/unhiding the gadget element or renavigating). I¹m sure there are some kinks I haven¹t noticed that I¹ll discover along the way. So would a DEFAULT setprefs-ui feature be useful to include back into the project or is this really something each container implementer should have to do? If it seems useful I¹ll see about writing this so that it¹s contributable (after I brush up on my javascript skills ). doug On 2/21/12 8:30 PM, "Ryan J Baxter" wrote: > Actually the view name to use for displaying preferences in a gadget was > defined in the spec in 2.0. See > http://opensocial-resources.googlecode.com/svn/spec/2.0.1/Core-Gadget.xml#gadg > ets.views.ViewType > . > > One other thing to think about with a container side implementation would > be the savings you would get from not having to make an RPC request from > the gadget to the container, but that is a pretty small savings. Also if > you have a dedicated view you will need to render the preferences view > each time you want to change a preferences, and then render the view you > were on before. With a container implementation you have one less view to > render. > > I am not to fond of putting this implementation in the common container > because I am pretty sure every container will end up overriding it to > match the look and feel of its container, I am not sure how much use it > would actually be. > > -Ryan > > > > > From: "Franklin, Matthew B." > To: "dev@shindig.apache.org" , > Date: 02/21/2012 05:33 PM > Subject:RE: User Prefs Panel Brainstorm > > > >> >-Original Message- >> >From: daviesd [mailto:davi...@oclc.org] >> >Sent: Tuesday, February 21, 2012 4:44 PM >> >To: shindig >> >Subject: User Prefs Panel Brainstorm >> > >> >I¹ve started to implement a User Prefs panel. I¹m thinking of > implementing >> >it as a feature. My problem is I¹m flip flopping between it being a >> >container feature v.s. a gadget feature. There are benefits and > drawbacks >> >to both. I kind of like having it as a gadget feature. It could provide > a >> >default implementation via a view (let¹s call it userprefspanel). If the >> >user didn¹t want the default then they could just not include the > feature, >> >but still provide the view. This requires the container to know the name > of >> >the view so that it can provide navigation chrome to get there. It also >> >requires the gadget to do specific things, which is fine for my 1st party >> >gadgets but not 3rd party. So then I flip back to the container > > We (Rave) will support both container and a gadget managed edit > preferences. The most recent release only has container generated forms, > but in 0.9-incubating we should have the ability to define a custom view. > This means that Rave gadget developers will only need to implement a view > with a name something like "edit_prefs" and set the flag when registering > the gadget. We will then test the flag when edit prefs is selected from > the chrome and take appropriate action. > > What that view name is we haven't decided. There was some discussion on > the spec list about what it should be ~1 yr ago but I haven't looked. > >> >implementation. It would simply provide a generic implementation and the >> >chrome implementer would just need to know how to initiate it. I know > the >> >Rave guys have done a bit of this and it seems to be completely container >> >implemented? Is anyone actively working on the common container and was >> >there future plans to implement it there? Just looking for some > feedback. >> > >> >Thanks. >> >doug > > >
User Prefs Panel Brainstorm
I¹ve started to implement a User Prefs panel. I¹m thinking of implementing it as a feature. My problem is I¹m flip flopping between it being a container feature v.s. a gadget feature. There are benefits and drawbacks to both. I kind of like having it as a gadget feature. It could provide a default implementation via a view (let¹s call it userprefspanel). If the user didn¹t want the default then they could just not include the feature, but still provide the view. This requires the container to know the name of the view so that it can provide navigation chrome to get there. It also requires the gadget to do specific things, which is fine for my 1st party gadgets but not 3rd party. So then I flip back to the container implementation. It would simply provide a generic implementation and the chrome implementer would just need to know how to initiate it. I know the Rave guys have done a bit of this and it seems to be completely container implemented? Is anyone actively working on the common container and was there future plans to implement it there? Just looking for some feedback. Thanks. doug
Re: [jira] [Updated] (SHINDIG-1672) The HttpRequest object is not available to GrantRequestHandlers
Li (and anyone else that is interested). I've reopened SHINDIG-1672 with a
more specific usecase. As I started using the the auth_code/access_token
flow I discovered that what was previously implemented didn't fully meet my
needs.
I've tested this fix locally and it does what I need it to do. If the other
flows need this logic someone with more knowledge than I have is going to
have to implement.
Thanks,
doug
On 1/31/12 10:00 AM, "Doug Davies (Updated) (JIRA)" wrote:
>
> [
> https://issues.apache.org/jira/browse/SHINDIG-1672?page=com.atlassian.jira.plu
> gin.system.issuetabpanels:all-tabpanel ]
>
> Doug Davies updated SHINDIG-1672:
> -
>
> Description:
> It would be nice if the GrantRequestHandler had access to the original request
> object so that it could use values like the security token to pass along
> additional params to the authorization code request. In our implementation we
> set values within the security token's trusted json field that we'd like to
> pass along to our GrantRequestHandler implementation.
>
> NEW USECASE (1/31/12):
>
> Allow additional parameters to be appended to both the auth code request
> (query string) and access token request (body).
>
> ** If the other 2 flows need to be updated that can be done as well, but I
> don't know enough about those flows to know where to plug in.
>
> Remove these lines
>
> for (Map.Entry entry :
> accessor.getAdditionalRequestParams().entrySet()) {
>request.setParam(entry.getKey(), entry.getValue());
> }
>
> From BasicAuthenticationHandler, ClientCredentialsGrantTypeHandler, and
> StandardAuthenticationHandler.
>
> Leave the one in CodeGrantTypeHandler to support the additional parameters on
> the auth code request.
>
> THEN...add these lines to
> CodeAuthorizationResponseHandler:getAuthorizationBody to handle the access
> token request
>
> (right after queryParams.put(OAuth2Message.CLIENT_SECRET, secret); )
>
> for (Map.Entry entry :
> accessor.getAdditionalRequestParams().entrySet()) {
>queryParams.put(entry.getKey(), entry.getValue());
> }
>
>
>
> was:It would be nice if the GrantRequestHandler had access to the original
> request object so that it could use values like the security token to pass
> along additional params to the authorization code request. In our
> implementation we set values within the security token's trusted json field
> that we'd like to pass along to our GrantRequestHandler implementation.
>
>
> Please see updated use-case. I've discussed these changes with Li Xu and he is
> going to review.
>
>> The HttpRequest object is not available to GrantRequestHandlers
>> ---
>>
>> Key: SHINDIG-1672
>> URL: https://issues.apache.org/jira/browse/SHINDIG-1672
>> Project: Shindig
>> Issue Type: Bug
>> Components: Java
>>Affects Versions: 3.0.0
>>Reporter: Doug Davies
>> Fix For: 3.0.0
>>
>>
>> It would be nice if the GrantRequestHandler had access to the original
>> request object so that it could use values like the security token to pass
>> along additional params to the authorization code request. In our
>> implementation we set values within the security token's trusted json field
>> that we'd like to pass along to our GrantRequestHandler implementation.
>> NEW USECASE (1/31/12):
>> Allow additional parameters to be appended to both the auth code request
>> (query string) and access token request (body).
>> ** If the other 2 flows need to be updated that can be done as well, but I
>> don't know enough about those flows to know where to plug in.
>> Remove these lines
>> for (Map.Entry entry :
>> accessor.getAdditionalRequestParams().entrySet()) {
>>request.setParam(entry.getKey(), entry.getValue());
>> }
>> From BasicAuthenticationHandler, ClientCredentialsGrantTypeHandler, and
>> StandardAuthenticationHandler.
>> Leave the one in CodeGrantTypeHandler to support the additional parameters on
>> the auth code request.
>> THEN...add these lines to
>> CodeAuthorizationResponseHandler:getAuthorizationBody to handle the access
>> token request
>> (right after queryParams.put(OAuth2Message.CLIENT_SECRET, secret); )
>> for (Map.Entry entry :
>> accessor.getAdditionalRequestParams().entrySet()) {
>>queryParams.put(entry.getKey(), entry.getValue());
>> }
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators:
> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
GadgetSIte broke me
Dan, I hadn¹t updated my shindig artifacts in about a week. There were some changes to GadgetSite that broke me (my chrome around gadgets). Hopefully you can point me to substitutes. gadgetSite.currentGadgetEl_ - yes I realize I shouldn¹t have been using the private member, but I need access to the element this site is rendered into to apply some styles classes. I switched to el_, but I know this is just as bad. gadgetSite.getActiveGadgetHolder looks like it changed to getActiveSiteHolder. Is this the equivalent? I¹m using it for .getView(), .getGadgetInfo().views, and .getUrl(). Thanks, doug
Re: OAuth2RequestParameterGenerator
I debugged through this a little more today and it¹s not as simple as
putting the http request params into the http method params used in the
fetcher. It appears for the access token flow that the parameters are
POSTED via a body created by CodeAuthorizationResponseHandler. It only
looks for specific parameters (grant_type, authorization, redirect_uri,
etc.) to pass to the access token request and so the extra parameters I add
in StandardAuthenticationHandler really don¹t matter. If anyone is familiar
with all this I could use some direction as to where to plug in here.
Thanks!
doug
On 1/27/12 3:25 PM, "daviesd" wrote:
> I¹m just wondering if it¹s as easy as having BasicHttpFetcher transfer the
> HttpRequest params to the httpMethod params. Was it an oversight or were they
> not copied for a reason?
>
> doug
>
> On 1/27/12 2:23 PM, "daviesd" wrote:
>
>> Back in December Li Xu helped me get a patch submitted that added the
>> OAuth2RequestParameterGenerator interface. It is meant to be implemented if
>> you want to pass additional parameters along to the various oauth2 flow
>> requests.
>>
>> I¹ve since noticed an issue with this. The parameters I add get passed along
>> fine to a CodeGrantTypeHandler (when asking for the auth code). However,
>> when the access token is requested using the StandardAuthenticationHandler,
>> the parameters I generate do not get passed along the subsequent
>> BasicHttpFetcher.fetch. I think probably because this is a POST and it
>> doesn¹t pass parameters sent in the HttpRequest object. It assumes only
>> header values? Is this correct or a bug? Should I be passing my additional
>> parameters along in the header in this case? If so, I probably need to
>> supply a patch for StandardAuthenticationHandler that adds the params to the
>> header in addition.
>>
>> request.setHeader(OAuth2Message.CLIENT_ID, clientId);
>> request.setParam(OAuth2Message.CLIENT_ID, clientId);
>> request.setHeader(OAuth2Message.CLIENT_SECRET, secret);
>> request.setParam(OAuth2Message.CLIENT_SECRET, secret);
>>
>> // add any additional parameters
>> for (Map.Entry entry :
>> accessor.getAdditionalRequestParams().entrySet()) {
>> request.setParam(entry.getKey(), entry.getValue());
>> }
>>
>> doug
Re: OAuth2RequestParameterGenerator
I¹m just wondering if it¹s as easy as having BasicHttpFetcher transfer the
HttpRequest params to the httpMethod params. Was it an oversight or were
they not copied for a reason?
doug
On 1/27/12 2:23 PM, "daviesd" wrote:
> Back in December Li Xu helped me get a patch submitted that added the
> OAuth2RequestParameterGenerator interface. It is meant to be implemented if
> you want to pass additional parameters along to the various oauth2 flow
> requests.
>
> I¹ve since noticed an issue with this. The parameters I add get passed along
> fine to a CodeGrantTypeHandler (when asking for the auth code). However, when
> the access token is requested using the StandardAuthenticationHandler, the
> parameters I generate do not get passed along the subsequent
> BasicHttpFetcher.fetch. I think probably because this is a POST and it
> doesn¹t pass parameters sent in the HttpRequest object. It assumes only
> header values? Is this correct or a bug? Should I be passing my additional
> parameters along in the header in this case? If so, I probably need to supply
> a patch for StandardAuthenticationHandler that adds the params to the header
> in addition.
>
> request.setHeader(OAuth2Message.CLIENT_ID, clientId);
> request.setParam(OAuth2Message.CLIENT_ID, clientId);
> request.setHeader(OAuth2Message.CLIENT_SECRET, secret);
> request.setParam(OAuth2Message.CLIENT_SECRET, secret);
>
> // add any additional parameters
> for (Map.Entry entry :
> accessor.getAdditionalRequestParams().entrySet()) {
> request.setParam(entry.getKey(), entry.getValue());
> }
>
> doug
OAuth2RequestParameterGenerator
Back in December Li Xu helped me get a patch submitted that added the
OAuth2RequestParameterGenerator interface. It is meant to be implemented if
you want to pass additional parameters along to the various oauth2 flow
requests.
I¹ve since noticed an issue with this. The parameters I add get passed
along fine to a CodeGrantTypeHandler (when asking for the auth code).
However, when the access token is requested using the
StandardAuthenticationHandler, the parameters I generate do not get passed
along the subsequent BasicHttpFetcher.fetch. I think probably because this
is a POST and it doesn¹t pass parameters sent in the HttpRequest object. It
assumes only header values? Is this correct or a bug? Should I be passing
my additional parameters along in the header in this case? If so, I
probably need to supply a patch for StandardAuthenticationHandler that adds
the params to the header in addition.
request.setHeader(OAuth2Message.CLIENT_ID, clientId);
request.setParam(OAuth2Message.CLIENT_ID, clientId);
request.setHeader(OAuth2Message.CLIENT_SECRET, secret);
request.setParam(OAuth2Message.CLIENT_SECRET, secret);
// add any additional parameters
for (Map.Entry entry :
accessor.getAdditionalRequestParams().entrySet()) {
request.setParam(entry.getKey(), entry.getValue());
}
doug
Re: getModuleId
That's what I was kind of figuring. So can you tell me what state the moduleId stuff is at? Is it still under development or can I start using it now? I hope we get another beta (or final 3.0.0 release) soon that has this and oauth2 in a stable state. doug On 1/23/12 3:16 PM, "Dan Dumont" wrote: > Hrmm... > > I don't know if you'll be able to do this anymore until you hook up the > moduleId support. > > > > From: daviesd > To: , > Date: 01/23/2012 03:08 PM > Subject:Re: getModuleId > > > > Like I said... An edge case... And probably not a real world use case. > > But my test gadget sets a bunch of userprefs and then it needs to repull > the > values (from persistence) and make sure they've been set properly (tests a > race condition we had). > > I was using osapi.userprefs.get to retrieve the values. Is there a gadget > way of triggering the get call that is in the container? I don't want to > just get the map that the container has, I need to reforce a read from > persistence. > > Hope that makes sense, > doug > > > On 1/23/12 3:00 PM, "Dan Dumont" wrote: > >> I don't think so. In my opinion, the siteId is a purely container > piece >> of information. >> why do you need to get it inside the gadget? >> >> >> >> From: daviesd >> To: , >> Date: 01/23/2012 02:57 PM >> Subject:Re: getModuleId >> >> >> >> I agree on everything you just stated. >> >> So my only outstanding question would be is anyone aware of a way for a >> gadget to find out it's siteId (the id that was set on the element the >> gadget was rendered into)? >> >> Any yes, I'd like to see the rpc requests changed to use the gadget >> security >> token. >> >> doug >> >> >> On 1/23/12 1:44 PM, "Dan Dumont" wrote: >> >>> Not a problem. >>> >>> mid is for the moduleId. (maybe it wasn't always so... but for >>> consistency sake it probably should remain so) >>> IIRC, Prefs.getModuleId returns the value in the ifr url 'mid' param. >>> >>> Your GET_PREFERENCES/SET_PREFERENCES impl should be getting the siteid, >>> which it can look up a gadget site with. >>> You can then determine the moduleId (which should be 0 for now). >>> >>> I agree, if the rpc requests do not pass the gadget's token along, they >>> probably should now. Most people will be wanting to key things off of >> the >>> moduleId rather than the siteId. The moduleId is baked in the token > and >>> not something one could spoof with firebug. >>> >>> >>> From: daviesd >>> To: , >>> Date: 01/23/2012 01:34 PM >>> Subject:Re: getModuleId >>> >>> >>> >>> In pref.js shindig was setting the Prefs moduleId to the "mid" >> parameter. >>> Perhaps something is different here now. So for whatever reason that >> use >>> to >>> return me whatever I had as my siteId and now it doesn't. >>> >>> At any rate, this is a TEST gadget that is probably trying to access >>> something it shouldn't. When the userprefs are stored they are stored >>> using >>> the siteId granted by our container implementation (the container >>> registers >>> SET_PREFERENCES and GET_PREFERENCES handlers). I think I opened up > this >>> ticket because of that. >>> >>> https://issues.apache.org/jira/browse/SHINDIG-1557 >>> >>> It would really be nice if the rpc requests used the gadget security >> token >>> (that would hopefully have the moduleId set now that you've implemented >>> that). >>> >>> So in my test gadget I don't know what the siteId is. For some reason > I >>> was >>> calling Prefs().getModuleId (I think this thread suggests that). >>> >>> http://shindig-dev.markmail.org/thread/zyi2zvpn7akhrbi3 >>> >>> Is there another way for a gadget to know this? I realize implementing >>> moduleId would probably give me this (although a gadget doesn't really >>> know >>> what's in it's security token, but it can certainly pass it along to > api >>> calls). >>> >>> Sorry if I'm muddying the waters. I should have been more active in >> your >>> moduleId discussion. >>> &g
Re: getModuleId
Like I said... An edge case... And probably not a real world use case.
But my test gadget sets a bunch of userprefs and then it needs to repull the
values (from persistence) and make sure they've been set properly (tests a
race condition we had).
I was using osapi.userprefs.get to retrieve the values. Is there a gadget
way of triggering the get call that is in the container? I don't want to
just get the map that the container has, I need to reforce a read from
persistence.
Hope that makes sense,
doug
On 1/23/12 3:00 PM, "Dan Dumont" wrote:
> I don't think so. In my opinion, the siteId is a purely container piece
> of information.
> why do you need to get it inside the gadget?
>
>
>
> From: daviesd
> To: ,
> Date: 01/23/2012 02:57 PM
> Subject:Re: getModuleId
>
>
>
> I agree on everything you just stated.
>
> So my only outstanding question would be is anyone aware of a way for a
> gadget to find out it's siteId (the id that was set on the element the
> gadget was rendered into)?
>
> Any yes, I'd like to see the rpc requests changed to use the gadget
> security
> token.
>
> doug
>
>
> On 1/23/12 1:44 PM, "Dan Dumont" wrote:
>
>> Not a problem.
>>
>> mid is for the moduleId. (maybe it wasn't always so... but for
>> consistency sake it probably should remain so)
>> IIRC, Prefs.getModuleId returns the value in the ifr url 'mid' param.
>>
>> Your GET_PREFERENCES/SET_PREFERENCES impl should be getting the siteid,
>> which it can look up a gadget site with.
>> You can then determine the moduleId (which should be 0 for now).
>>
>> I agree, if the rpc requests do not pass the gadget's token along, they
>> probably should now. Most people will be wanting to key things off of
> the
>> moduleId rather than the siteId. The moduleId is baked in the token and
>> not something one could spoof with firebug.
>>
>>
>> From: daviesd
>> To: ,
>> Date: 01/23/2012 01:34 PM
>> Subject:Re: getModuleId
>>
>>
>>
>> In pref.js shindig was setting the Prefs moduleId to the "mid"
> parameter.
>> Perhaps something is different here now. So for whatever reason that
> use
>> to
>> return me whatever I had as my siteId and now it doesn't.
>>
>> At any rate, this is a TEST gadget that is probably trying to access
>> something it shouldn't. When the userprefs are stored they are stored
>> using
>> the siteId granted by our container implementation (the container
>> registers
>> SET_PREFERENCES and GET_PREFERENCES handlers). I think I opened up this
>> ticket because of that.
>>
>> https://issues.apache.org/jira/browse/SHINDIG-1557
>>
>> It would really be nice if the rpc requests used the gadget security
> token
>> (that would hopefully have the moduleId set now that you've implemented
>> that).
>>
>> So in my test gadget I don't know what the siteId is. For some reason I
>> was
>> calling Prefs().getModuleId (I think this thread suggests that).
>>
>> http://shindig-dev.markmail.org/thread/zyi2zvpn7akhrbi3
>>
>> Is there another way for a gadget to know this? I realize implementing
>> moduleId would probably give me this (although a gadget doesn't really
>> know
>> what's in it's security token, but it can certainly pass it along to api
>> calls).
>>
>> Sorry if I'm muddying the waters. I should have been more active in
> your
>> moduleId discussion.
>>
>> doug
>>
>>
>> On 1/23/12 12:57 PM, "Dan Dumont" wrote:
>>
>>> Hrmm... I don't recall moduleId ever being anything other than 0.
>>>
>>> The discussions have focused around what a moduleId is (a number that's
>>> baked into the security token, primarily used to identify saved
>> instances
>>> of a gadget) and what a siteId is ( a string value that's used in or as
>> an
>>> id attribute of a DOM element in the container ). The recent patches
>>> created a way to generate, save, and track moduleIds on the server,
>> should
>>> you choose to implement the bits, otherwise they return 0 as they
> always
>>> have.
>>>
>>> I'm curious how you got numbers other than 0. Especially for the
>> security
>>> token, moduleId was always 0 in shindig.
>>>
>>>
>>>
>>> From: daviesd
>>> To: shindig ,
>>> Date: 01/23/2012 12:51 PM
>>> Subject:getModuleId
>>>
>>>
>>>
>>> I have a gadget that was using
>>>
>>> var moduleId = new gadgets.Prefs().getModuleId();
>>>
>>> To get the current moduleId (siteId) of the gadget so that it could
>>> retrieve
>>> userprefs
>>>
>>> osapi.userprefs.get( { siteId : moduleId } )
>>>
>>> This is now return 0 instead of the id I have for the element the
> gadget
>>> was
>>> rendered into.
>>>
>>> I haven¹t kept up with the whole moduleId/siteId patch that is going
> on,
>>> but
>>> perhaps something has changed here and is not backwards compatible?
>>>
>>> Any ideas? It¹s been a while since I¹ve played around with userprefs
>> and
>>> today was the first I noticed it wasn¹t working.
>>>
>>> doug
>>>
>>
>>
>>
>
>
>
Re: getModuleId
I agree on everything you just stated.
So my only outstanding question would be is anyone aware of a way for a
gadget to find out it's siteId (the id that was set on the element the
gadget was rendered into)?
Any yes, I'd like to see the rpc requests changed to use the gadget security
token.
doug
On 1/23/12 1:44 PM, "Dan Dumont" wrote:
> Not a problem.
>
> mid is for the moduleId. (maybe it wasn't always so... but for
> consistency sake it probably should remain so)
> IIRC, Prefs.getModuleId returns the value in the ifr url 'mid' param.
>
> Your GET_PREFERENCES/SET_PREFERENCES impl should be getting the siteid,
> which it can look up a gadget site with.
> You can then determine the moduleId (which should be 0 for now).
>
> I agree, if the rpc requests do not pass the gadget's token along, they
> probably should now. Most people will be wanting to key things off of the
> moduleId rather than the siteId. The moduleId is baked in the token and
> not something one could spoof with firebug.
>
>
> From: daviesd
> To: ,
> Date: 01/23/2012 01:34 PM
> Subject:Re: getModuleId
>
>
>
> In pref.js shindig was setting the Prefs moduleId to the "mid" parameter.
> Perhaps something is different here now. So for whatever reason that use
> to
> return me whatever I had as my siteId and now it doesn't.
>
> At any rate, this is a TEST gadget that is probably trying to access
> something it shouldn't. When the userprefs are stored they are stored
> using
> the siteId granted by our container implementation (the container
> registers
> SET_PREFERENCES and GET_PREFERENCES handlers). I think I opened up this
> ticket because of that.
>
> https://issues.apache.org/jira/browse/SHINDIG-1557
>
> It would really be nice if the rpc requests used the gadget security token
> (that would hopefully have the moduleId set now that you've implemented
> that).
>
> So in my test gadget I don't know what the siteId is. For some reason I
> was
> calling Prefs().getModuleId (I think this thread suggests that).
>
> http://shindig-dev.markmail.org/thread/zyi2zvpn7akhrbi3
>
> Is there another way for a gadget to know this? I realize implementing
> moduleId would probably give me this (although a gadget doesn't really
> know
> what's in it's security token, but it can certainly pass it along to api
> calls).
>
> Sorry if I'm muddying the waters. I should have been more active in your
> moduleId discussion.
>
> doug
>
>
> On 1/23/12 12:57 PM, "Dan Dumont" wrote:
>
>> Hrmm... I don't recall moduleId ever being anything other than 0.
>>
>> The discussions have focused around what a moduleId is (a number that's
>> baked into the security token, primarily used to identify saved
> instances
>> of a gadget) and what a siteId is ( a string value that's used in or as
> an
>> id attribute of a DOM element in the container ). The recent patches
>> created a way to generate, save, and track moduleIds on the server,
> should
>> you choose to implement the bits, otherwise they return 0 as they always
>> have.
>>
>> I'm curious how you got numbers other than 0. Especially for the
> security
>> token, moduleId was always 0 in shindig.
>>
>>
>>
>> From: daviesd
>> To: shindig ,
>> Date: 01/23/2012 12:51 PM
>> Subject:getModuleId
>>
>>
>>
>> I have a gadget that was using
>>
>> var moduleId = new gadgets.Prefs().getModuleId();
>>
>> To get the current moduleId (siteId) of the gadget so that it could
>> retrieve
>> userprefs
>>
>> osapi.userprefs.get( { siteId : moduleId } )
>>
>> This is now return 0 instead of the id I have for the element the gadget
>> was
>> rendered into.
>>
>> I haven¹t kept up with the whole moduleId/siteId patch that is going on,
>> but
>> perhaps something has changed here and is not backwards compatible?
>>
>> Any ideas? It¹s been a while since I¹ve played around with userprefs
> and
>> today was the first I noticed it wasn¹t working.
>>
>> doug
>>
>
>
>
Re: getModuleId
In pref.js shindig was setting the Prefs moduleId to the "mid" parameter.
Perhaps something is different here now. So for whatever reason that use to
return me whatever I had as my siteId and now it doesn't.
At any rate, this is a TEST gadget that is probably trying to access
something it shouldn't. When the userprefs are stored they are stored using
the siteId granted by our container implementation (the container registers
SET_PREFERENCES and GET_PREFERENCES handlers). I think I opened up this
ticket because of that.
https://issues.apache.org/jira/browse/SHINDIG-1557
It would really be nice if the rpc requests used the gadget security token
(that would hopefully have the moduleId set now that you've implemented
that).
So in my test gadget I don't know what the siteId is. For some reason I was
calling Prefs().getModuleId (I think this thread suggests that).
http://shindig-dev.markmail.org/thread/zyi2zvpn7akhrbi3
Is there another way for a gadget to know this? I realize implementing
moduleId would probably give me this (although a gadget doesn't really know
what's in it's security token, but it can certainly pass it along to api
calls).
Sorry if I'm muddying the waters. I should have been more active in your
moduleId discussion.
doug
On 1/23/12 12:57 PM, "Dan Dumont" wrote:
> Hrmm... I don't recall moduleId ever being anything other than 0.
>
> The discussions have focused around what a moduleId is (a number that's
> baked into the security token, primarily used to identify saved instances
> of a gadget) and what a siteId is ( a string value that's used in or as an
> id attribute of a DOM element in the container ). The recent patches
> created a way to generate, save, and track moduleIds on the server, should
> you choose to implement the bits, otherwise they return 0 as they always
> have.
>
> I'm curious how you got numbers other than 0. Especially for the security
> token, moduleId was always 0 in shindig.
>
>
>
> From: daviesd
> To: shindig ,
> Date: 01/23/2012 12:51 PM
> Subject:getModuleId
>
>
>
> I have a gadget that was using
>
> var moduleId = new gadgets.Prefs().getModuleId();
>
> To get the current moduleId (siteId) of the gadget so that it could
> retrieve
> userprefs
>
> osapi.userprefs.get( { siteId : moduleId } )
>
> This is now return 0 instead of the id I have for the element the gadget
> was
> rendered into.
>
> I haven¹t kept up with the whole moduleId/siteId patch that is going on,
> but
> perhaps something has changed here and is not backwards compatible?
>
> Any ideas? It¹s been a while since I¹ve played around with userprefs and
> today was the first I noticed it wasn¹t working.
>
> doug
>
getModuleId
I have a gadget that was using
var moduleId = new gadgets.Prefs().getModuleId();
To get the current moduleId (siteId) of the gadget so that it could retrieve
userprefs
osapi.userprefs.get( { siteId : moduleId } )
This is now return 0 instead of the id I have for the element the gadget was
rendered into.
I haven¹t kept up with the whole moduleId/siteId patch that is going on, but
perhaps something has changed here and is not backwards compatible?
Any ideas? It¹s been a while since I¹ve played around with userprefs and
today was the first I noticed it wasn¹t working.
doug
Re: No snapshot since the new year
Thanks Paul! On 1/10/12 6:50 PM, "Paul Lindner" wrote: > JENKINS-12259 caused the build server to do bad things. > I just updated and kicked off a SNAPSHOT build. Should be available in the > next hour or so. > > > > On Tue, Jan 10, 2012 at 3:44 PM, daviesd wrote: > >> I hate to be a pest, but does anyone have an update on this? I¹m still >> only >> seeing 12/26 as the latest artifact. This is affecting my daily build. >> >> Thanks, >> doug >> >> >> On 1/9/12 1:28 PM, "daviesd" wrote: >> >>> Any ideas on this? I¹m still showing 12/26 as the last builds at >>> >>> >> https://repository.apache.org/content/groups/public/org/apache/shindig/shindi>> g >>> -common/3.0.0-SNAPSHOT/ >>> >>> Also, ideas when we might see a beta5? >>> >>> doug >>> >>> >>> On 1/6/12 9:58 AM, "daviesd" wrote: >>> >>>> Thanks. Are snapshots happening? I don¹t seem to be picking up anything >> new >>>> since 12/26. Could be an issue on my end. >>>> >>>> doug >>>> >>>> >>>> On 1/3/12 4:21 PM, "Paul Lindner" wrote: >>>> >>>>> ugh. I reverted the revert. I'll get it back in place. >>>>> >>>>> >>>>> commit f30c4decb5332f18acbacacedd29dee7df54b12e >>>>> Author: Paul Lindner >>>>> Date: Mon Dec 26 10:44:42 2011 + >>>>> >>>>> fix deprecated usage for httpclient >>>>> >>>>> git-svn-id: >>>>> >> https://svn.apache.org/repos/asf/shindig/trunk@122470813f79535-47bb-0310-995 >>>>> 6-ffa450edef68 >>>>> >>>>> >>>>> On Tue, Jan 3, 2012 at 12:46 PM, daviesd wrote: >>>>> >>>>>>> Did this change again recently? The ssl certificate error is back. >>>>>>> >>>>>>> doug >>>>>>> >>>>>>> >>>>>>> On 11/7/11 1:45 PM, "Ryan J Baxter" wrote: >>>>>>> >>>>>>>>> I have been seeing SSL exceptions being thrown relating to >>>>>>> certificates >>>>>>>>> not matching in builds from trunk recently. I have traced this >> back >>>>>>> to a >>>>>>>>> httpclient upgrade from 4.1.1 to 4.1.2. Would anyone be opposed >> to >>>>>>>>> reverting back to 4.1.1 for the time being? >>>>>>>>> >>>>>>>>> Looking that the changes that went into 4.1.2, this change looks >> like >> it >>>>>>>>> might be related to the problem. I have CCed Sebastian, maybe >> he can >>>>>>>>> confirm. >>>>>>>>> >>>>>>>>> * [HTTPCLIENT-1097] BrowserCompatHostnameVerifier and >>>>>>>>> StrictHostnameVerifier should handle >>>>>>>>> wildcards in SSL certificates better. >>>>>>>>> Contributed by Sebastian Bazley >>>>>>>>> >>>>>>>>> INFO: The following exception occurred when fetching >>>>>>>>> https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js: >> 405 >> ms >>>>>>>>> elapsed. >>>>>>>>> Nov 7, 2011 1:38:28 PM >>>>>>> org.apache.shindig.gadgets.http.BasicHttpFetcher >>>>>>>>> fetch >>>>>>>>> INFO: >>>>>>>>> javax.net.ssl.SSLException: hostname in certificate didn't match: >>>>>>>>> != <*.googleapis.com> OR >>>>>>>>> OR <*.googleapis.com> >>>>>>>>> at org.apache.http.conn.ssl.AbstractVerifier.verify( >>>>>>>>> AbstractVerifier.java:228) >>>>>>>>> at >>>>>>> org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify( >>>>>>>>> BrowserCompatHostnameVerifier.java:54) >>>>>>>>> at org.apache.http.conn.ssl.AbstractVerifier.verify( >>>>>>>>> AbstractVerifier.java:149) >>>>>>>>> at org.apache.http.conn.ssl.AbstractVerifier.
