upgrading 2.0.0 to 2.5.1

[Tylor Dippel <ty...@gmail.com>]

I am working on an application that utilizes Shindig 2.0.0, and am
attempting to upgrade to Shindig 2.5.1. I've encountered an issue where
makeRequests always fail. With Shindig 2.0.0, makeRequest()s were sent out
from the browser as an AJAX POST, but with 2.5.1, requests are instead
being sent out as a GET, and I'm not sure why--although the GET appears to
use query parameters that more or less match the POST data in the requests
that were sent using 2.0.0. Also, the makeRequests fail with an Error 404
in the browser, but when I copy and paste the failed request URL into the
browser's address bar, the correct data comes back as expected (no 404).



 Does anyone have any idea why this might be happening?

Re: upgrading 2.0.0 to 2.5.1

[Stanton Sievers <ss...@apache.org>]

Hi Tylor,

Do you have any particular setup with regards to locked or unlocked
domains?  makeRequests are made from the domain that the gadgets are
rendering on.  If there is a configuration problem and the makeRequest is
happening on a domain that is not the same as the gadget iframe domain, the
browser's same origin policy will block the request.

There is a page that outlines locked domains [1] configuration.  You can
cross-reference with your configuration to see how it lines up.

Regards,
-Stanton

[1] https://cwiki.apache.org/confluence/display/SHINDIG/Locked+Domains


On Tue, May 6, 2014 at 5:55 PM, Tylor Dippel <ty...@gmail.com> wrote:

> I am working on an application that utilizes Shindig 2.0.0, and am
> attempting to upgrade to Shindig 2.5.1. I've encountered an issue where
> makeRequests always fail. With Shindig 2.0.0, makeRequest()s were sent out
> from the browser as an AJAX POST, but with 2.5.1, requests are instead
> being sent out as a GET, and I'm not sure why--although the GET appears to
> use query parameters that more or less match the POST data in the requests
> that were sent using 2.0.0. Also, the makeRequests fail with an Error 404
> in the browser, but when I copy and paste the failed request URL into the
> browser's address bar, the correct data comes back as expected (no 404).
>
>
>
>  Does anyone have any idea why this might be happening?
>