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 <[email protected]> To: <[email protected]>, 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" <[email protected]> wrote: > Doug add shindig.urlgen.use-templates-default=false to your > shindig.properties file and try again. > > -Ryan > > > > > From: daviesd <[email protected]> > To: <[email protected]>, > 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" <[email protected]> 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" <[email protected]> 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 <[email protected]> >>> To: shindig <[email protected]>, >>> 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 >>> >>> > > >
