---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3670/#review4699
---
Committed revision 1238135.
- Ryan
On 2012-01-30 15:29:59, Ryan Bax
I'm looking at the response from makeRequest and was reminded that we do:
// Always set Content-Disposition header as XSS prevention mechanism.
response.setHeader("Content-Disposition", "attachment;filename=p.txt"
);
I'm wondering what people think about not doing this in a shindig config
For currentGadgetEl_ please use ,el_I know it's also private... you
could request or submit a patch to add a getter for the new site class.
For getActiveGadgetHolder, yes you should now use getActiveSiteHolder
From: daviesd
To: shindig ,
Date: 01/30/2012 06:02 PM
Subject:
Dan,
I hadn¹t updated my shindig artifacts in about a week. There were some
changes to GadgetSite that broke me (my chrome around gadgets). Hopefully
you can point me to substitutes.
gadgetSite.currentGadgetEl_ - yes I realize I shouldn¹t have been using the
private member, but I need access to
I debugged through this a little more today and it¹s not as simple as
putting the http request params into the http method params used in the
fetcher. It appears for the access token flow that the parameters are
POSTED via a body created by CodeAuthorizationResponseHandler. It only
looks for spec
We ran into this problem when we had an app that was using flash. We
essentially created a short lived, one time use token that the javascript
part of the app could ask for. It then gives it to the flash part of the
app that invokes the upload. Here's the binary api I'm talking about:
http://docs.j
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3666/#review4691
---
Ship it!
LGTM
- Ryan
On 2012-01-27 22:11:34, Henry Saputra wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3670/#review4690
---
Ship it!
LGTM
- Stanton
On 2012-01-30 15:29:59, Ryan Baxter wrote:
> On 2012-01-28 15:17:28, Stanton Sievers wrote:
> > My biggest concern with this change is that it breaks backwards
> > compatibility. There is no longer "iframeurl" on the metadata responses.
> > This isn't a big deal if everyone is using the common container, since
> > you've updated that
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3670/
---
(Updated 2012-01-30 15:29:59.387801)
Review request for shindig.
Changes
-
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3670/#review4687
---
LGTM other than the comments Stanton already made. Re: backcompat, if
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3695/
---
(Updated 2012-01-30 13:38:57.710474)
Review request for shindig.
Changes
-
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3695/
---
(Updated 2012-01-30 13:16:15.179882)
Review request for shindig.
Changes
-
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3695/
---
Review request for shindig.
Summary
---
This is an *artificial* patch showi
14 matches
Mail list logo
