>-----Original Message-----
>From: Davies,Douglas [mailto:davi...@oclc.org]
>Sent: Thursday, March 31, 2011 5:27 PM
>To: dev@shindig.apache.org
>Subject: RE: Shindig and webapp on same host/domain or not?
>
>Isaiah,
>
>Were you successful on getting this to work?  I tried a similar approach
>today using urlrewritefilter with the mapping:
>
>        <from>/shindig/**</from>
>        <to type="redirect">http://myshindigserver/shindig/$1</to>

I haven't used urlrewritefilter myself, but that configuration looks to me like 
it's going to end up sending a 302 redirect to the client -- so you're still 
going to end up with the cross domain XHR happening on the client side which is 
going to fail.  I think you're on the right track though -- you just need to be 
sure the fetch to shindig happens from the server side (you want to proxy the 
client request rather than redirect it).  I'm not sure whether or not 
urlrewritefilter supports that though.

I'd say the server side proxy approach is probably the simplest and most 
reliable way to go about this though -- I think for the hidden iframe stuff to 
work you need coordination on both sides of the request.  Shindig actually does 
this though for gadgets RPC (to allow gadgets running on domain X to make RPC 
calls via JavaScript to their container page running on domain Y).  Shindig 
tries to use a bunch of other faster/supported/more reliable approaches first 
but falls back to IFPC if all other attempts fail.  You could look at that code 
for inspiration if you decide to go that route:

http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/rpc/

and more specifically:

http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/rpc/ifpc.transport.js

>
>I see the request now changing using firebug
>
>http://myshindigserver/shindig/rpc?st=-1%3A-1%3A*%3A%3A*%3A0%3Aoclc
>
>but it returns a 400 (Bad Request) because there is NO post data.  There
>should be a JSON post data with the gadgets to return info about (at
>least that's what I see on the request when they are on the same
>domain).  This is EXACTLY the same symptom I saw if I just hardcoded the
>fully qualified dns name of in container.js.
>
>I'm wondering if Michael Hermanto's idea to use an iframe is going to
>behave any differently.
>
>So for now we are stuck running our shindig server and webapp on the
>same domain.
>
>doug
>
>-----Original Message-----
>From: Isaiah Billingsley [mailto:isaiah.billings...@caseware.com]
>Sent: Tuesday, March 29, 2011 3:56 PM
>To: dev@shindig.apache.org
>Subject: Re: Shindig and webapp on same host/domain or not?
>
>Hi Doug,
>
>I was the one asking this same question earlier in the thread you
>linked.
>
>What I ended up doing (or rather, what I am still in the process of
>implementing) was to run my webapp on a separate server from Shindig,
>but with a rewrite rule on my webapp server to my Shindig server.
>
>e.g. http://www.mywebapp.com/shindig/(.*)$  -->
>http://www.myshindig.com/$1
>
>This allows my container page to make requests to the shindig server,
>since the request is to the same domain. It also gives me the security
>of scenario 3, because the gadget iframes are still rendered on
>www.myshindig.com as per container config.
>
>
>Isaiah
>
>
>

Reply via email to