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" <rjbax...@us.ibm.com> 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 <davi...@oclc.org> > To: <dev@shindig.apache.org>, > 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" <ssiev...@us.ibm.com> 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 <davi...@oclc.org> >> To: <dev@shindig.apache.org>, >> 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" <rjbax...@us.ibm.com> wrote: >> >>> Doug add shindig.urlgen.use-templates-default=false to your >>> shindig.properties file and try again. >>> >>> -Ryan >>> >>> >>> >>> >>> From: daviesd <davi...@oclc.org> >>> To: <dev@shindig.apache.org>, >>> 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" <davi...@oclc.org> 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" <ddum...@us.ibm.com> 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 <davi...@oclc.org> >>>>> To: shindig <dev@shindig.apache.org>, >>>>> 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 >>>>> >>>>> >>> >>> >>> >> >> >> > > >
