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 >>>> >>>> >> >> >> > > >
