Here are my 2 cents...
For 1.c and 2.a I am not sure how true that is anymore...while some of
those files still exist in Shindig, I am willing to guess that have been
modified and are no longer the same as what is in
http://opensocial-resources.googlecode.com/svn/spec/0.8/. Would we have
to g
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3064/#review4719
---
seems okay. I wish I had the time to use Request-Scoped guice injecti
There seems to me to be a mismatch in expectations between gadget and
server if the makeRequest REFRESH param is set to 0, resulting in incorrect
caching of the request on the server.
If a gadget uses makeRequest and sets the REFRESH param = 0, then the
request is issued as a POST to the server,
>-Original Message-
>From: Dan Dumont [mailto:ddum...@us.ibm.com]
>Sent: Tuesday, January 31, 2012 11:28 AM
>To: dev@shindig.apache.org
>Subject: Re: makeRequest content-disposition header to prevent XSS
>
>Well...
>
>If the shindig server is locked down and properly secured, what
>vulnerab
Well...
If the shindig server is locked down and properly secured, what
vulnerability is the Content-Disposition protecting against?
And if the shindig server is not locked down and secured, does the server
owner really care about security?
Can we just remove this protection altogether and jus
Li (and anyone else that is interested). I've reopened SHINDIG-1672 with a
more specific usecase. As I started using the the auth_code/access_token
flow I discovered that what was previously implemented didn't fully meet my
needs.
I've tested this fix locally and it does what I need it to do. I
Would this mean that your changes would only work on IE if locked domains
are enabled and "secure" security tokens are turned on?
-Ryan
From: Dan Dumont/Westford/IBM@Lotus
To: dev@shindig.apache.org,
Date: 01/30/2012 06:29 PM
Subject:makeRequest content-disposition header to
Well,
the problem is basically caused by the last line in testframework.js
95: gadgets.util.registerOnLoadHandler(executeTest);
if gadget file requires "opensocial-0.9", alerts in executeTest are
collected by Java,
but as soon as gadget requires "osapi", the alerts are not collected
anymore.
