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: [email protected], 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 <[email protected]> To: [email protected], 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 <[email protected]> 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 <[email protected]> > To: [email protected], > 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 <[email protected]> > 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 <[email protected]> >> To: [email protected], >> 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 <[email protected]> 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" <[email protected]> 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: [email protected], >>>> 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 <[email protected]> >>>> To: [email protected], >>>> 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 <[email protected]> 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 >>>>> >>>> >>>> >>> >>> >> >> > >
