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