Ok, one step forward.  If I add

servletResponse.addHeader("Access-Control-Allow-Headers", "Content-Type");

It starts working and the gadget renders. Cool. But then the first
makeRequest from a gadget seems to be having difficulty.

doug


On 3/26/12 3:59 PM, "daviesd" <davi...@oclc.org> wrote:

> Started looking at this.  I'm a little unclear what I'm suppose to do if
> JsonRpcServlet receives an OPTIONS request.  Right now I was just trying the
> following (after allowing OPTIONS to pass-thru) right after the setCORSheader:
> 
>     if ("OPTIONS".equals(method)) {
>         
>         servletResponse.addHeader("Access-Control-Allow-Origin", "*");
>         servletResponse.addHeader("Access-Control-Max-Age", "3600");
>         servletResponse.addHeader("Access-Control-Allow-Methods", "POST, GET,
> OPTIONS");
>         return;
>     }
> 
> The pre-flight request now succeeds but I don't see any further requests from
> the javascript.  Probably my misunderstanding of CORS and XHR.  Any
> suggestions on how to best implement this?  Or perhaps I'm not gonna get off
> easy with just a few lines of code. :)
> 
> doug
> 
> 
> On 3/22/12 5:19 PM, "daviesd" <davi...@oclc.org> wrote:
> 
>> Again... Thanks Stanton for the quick response.  Ok, I'll probably spend a
>> few 
>> days with this next week and see what I can do.  I know nothing about CORS,
>> but I'll start reading up on it.
>> 
>> doug
>> 
>> 
>> On 3/22/12 5:13 PM, "Stanton Sievers" <ssiev...@us.ibm.com> wrote:
>> 
>>> Hi Doug,
>>> 
>>> That matches my findings as well.  I've not heard of anyone running the
>>> container page and shindig server on different domains without having to
>>> use a proxy on the container page's domain.
>>>  
>>> 
>>>  I'm sure it can be done it just doesn't appear to work with Shindig out
>>> of the box.  I think more would have to be done to implement CORS for the
>>> JsonRpcServlet.
>>> 
>>> Regards,
>>> -Stanton
>>> 
>>> 
>>> 
>>> From:   daviesd <davi...@oclc.org>
>>> To:     <dev@shindig.apache.org>,
>>> Date:   03/22/2012 17:08
>>> Subject:        Re: Shindig running on different domain than container
>>> REVISITED
>>> 
>>> 
>>> 
>>> Hi Stanton,
>>> 
>>> So is your earlier statement about things working just fine running the
>>> container page and shindig on different domains still true?  We are
>>> running
>>> a proxy just like you are (actually in production it's a load balancer
>>> rule).  I'd like to know if anyone has this working out of the box without
>>> a
>>> proxy and just the API_HOST and API_PATH config.  Hopefully someone can
>>> respond.
>>> 
>>> Mike started digging into this today and I'll continue next week (I'm in
>>> class this week), but I think his initial finding is that JsonRpcServlet
>>> is
>>> rejecting anything that isn't POST or GET (thus rejecting OPTIONS).
>>> 
>>> Thanks for the help.
>>> 
>>> doug
>>> 
>>> 
>>> On 3/22/12 11:30 AM, "Stanton Sievers" <ssiev...@us.ibm.com> wrote:
>>> 
>>>> Hi Mike,
>>>> 
>>>> I'm not sure even setting the headers would work (although I haven't
>>> tried
>>>> this in a while).  My recollection is that part of CORS is that an
>>> OPTIONS
>>>> request is sent to Shindig's rpc endpoint as part of the "pre-flight"
>>>> step.  The rpc servlet doesn't support OPTIONS and will return a 405.
>>> This
>>>> is something we could and probably should look at fixing in Shindig but
>>> no
>>>> one has taken the time to do so so far as I know.  Again, it's been a
>>>> while since I've investigated this so things may have changed.
>>>> 
>>>> The alternative, and what I've personally done, is have a proxy on the
>>>> container page's domain that can proxy the /rpc calls to Shindig.  That
>>>> works just fine.  You simply setup your API_HOST and API_PATH to utilize
>>>> the proxy url.
>>>> 
>>>> Hope that helps.
>>>> 
>>>> -Stanton
>>>> 
>>>> 
>>>> 
>>>> From:   Michael Matthews <matth...@oclc.org>
>>>> To:     <dev@shindig.apache.org>, Stanton Sievers/Westford/IBM@Lotus,
>>>> Cc:     Douglas Davies <davi...@oclc.org>
>>>> Date:   03/22/2012 11:17
>>>> Subject:        Re: Shindig running on different domain than container
>>>> REVISITED
>>>> 
>>>> 
>>>> 
>>>> First of all, thanks for the quick response to this.
>>>> 
>>>> I've modified our UI to pass the API_HOST and API_PATH as mentioned
>>> below.
>>>> I
>>>> know see an HTTP OPTIONS request failing.  From the browser's console:
>>>> 
>>>> XMLHttpRequest cannot load
>>>> 
>>> http://worldkat.dev.oclc.org/opensocial/rpc?st=oclc%3AilCK3wGsfqUWqIct7oHK19
>>> 
>>>> 
>>>> 
>>> RHViz9iHzb9ON-FGx5SeW_dk80zHiMOislNdLbszrLT-d6tjzTJw97nDIx92xDoCfQ3LW-JuWc8w
>>>> 
>>> k4HZrHckNYnMG9P1wiZtInHqq9-VqET8W-fusiWAAaazBul0ARi0RI2K6cJINxRZ7-7yhExX_Gny
>>>> 
>>> IW4PumEVYs9f6-6iRR6WsUEoKGATW13PtUM3NmDNZOhFI2E19l4yTlLibK2r68IN7LY_Lx6QJ6kl
>>>> 
>>> PN7a_cIe5IYBRFV-SAvcexnCfnnlp5gjbs9unXeGSDIedJesYi8daX0b4-DmUVFUMexi7e3txdCY
>>>> 
>>> inHExk7XYfbAgjc8Qpi8YEngUiTJzI2E5A02_Eb9B8kf5KEeaR4yKehI3DTKY6JTMCO6dQupqzu7
>>>> 
>>> oHDS2n7H3SgCIjpfzBycsrhiioiNJfOInQ0hd3FJ3g9U4geJzz_5mPli-vXB3xL6WaDL5wtXHYYT
>>>> GGVW0i_tKZKGTsjpFwLmD9gmytlt47pMEPW8zTWg. Origin http://localhost:8080
>>>> <http://localhost/>  is not allowed by Access-Control-Allow-Origin.
>>>> 
>>>> The OPTIONS request has the following headers set:
>>>> 
>>>> Access-Control-Request-Method: POST
>>>> Origin: http://localhost:8080
>>>> Access-Control-Request-Headers: Origin, Content-Type
>>>> 
>>>> I found the post
>>>> http://www.mail-archive.com/dev@shindig.apache.org/msg03230.html which
>>>> suggests additional configuration is required to set this in the PHP
>>>> version
>>>> of Shindig.
>>>> 
>>>> 
>>>> In the java version of shindig, is there additional configuration
>>> required
>>>> to set a Access-Control-Allow-Origin header on the response to allow the
>>>> cross-site request?
>>>> 
>>>> Thanks
>>>> Mike
>>>> 
>>>> 
>>>> On 3/22/12 7:23 AM, "Stanton Sievers" <ssiev...@us.ibm.com> wrote:
>>>> 
>>>>> From what I understand rpc_relay setup is only needed if you are using
>>>> the
>>>>> ifpc transport for rpc.  You can force this by setting
>>> useLegacyProtocol
>>>>> in your container config but why you would want to do that I do not
>>>> know.
>>>>> With modern browsers (html5) Shindig makes use of window.postMessage
>>>>>  (wpm) to do rpc and you don't have to worry about the relay setup.  In
>>>>> general the fallback for non-html 5 browsers is using a flash technique
>>>> if
>>>>> possible.  If you're interested in the way the rpc transport is chosen,
>>>>> you can check out rpc.js#getTransport() for more info.
>>>>> 
>>>>> -Stanton
>>>>> 
>>>>> 
>>>>> 
>>>>> From:   "Davies,Douglas" <davi...@oclc.org>
>>>>> To:     <dev@shindig.apache.org>,
>>>>> Date:   03/21/2012 20:28
>>>>> Subject:        Re: Shindig running on different domain than container
>>>>> REVISITED
>>>>> 
>>>>> 
>>>>> 
>>>>> Thanks Stanton. So no rpc_relay setup etc.?  Seems last time I did this
>>>> I
>>>>> ran into that.
>>>>> 
>>>>> Doug
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>> On Mar 21, 2012, at 3:43 PM, "Stanton Sievers" <ssiev...@us.ibm.com>
>>>>> wrote:
>>>>> 
>>>>>> Hi Doug,
>>>>>> 
>>>>>> Yes, things work just fine running the container page and shindig on
>>>>>> different domains.  You can set the
>>>>> osapi.container.ServiceConfig.API_HOST
>>>>>> and osapi.container.ServiceConfig.API_PATH when creating your
>>>>>> osapi.container.Container object to get the right pointers in place.
>>>>>> 
>>>>>> Best regards,
>>>>>> -Stanton
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> From:   daviesd <davi...@oclc.org>
>>>>>> To:     shindig <dev@shindig.apache.org>,
>>>>>> Date:   03/21/2012 13:04
>>>>>> Subject:        Shindig running on different domain than container
>>>>>> REVISITED
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> About a year ago there was a discussion about shindig running on a
>>>>>> different
>>>>>> domain than the container.
>>>>>> 
>>>>>> http://permalink.gmane.org/gmane.comp.web.shindig.devel/6824
>>>>>> 
>>>>>> Up till this point we have been running our shindig servers and our
>>>>>> container webapps on the same domain.  We¹d like to move away from
>>>> this.
>>>>> 
>>>>>> Is
>>>>>> this possible with shindig 2.5.0?  Have there been changes since this
>>>>>> discussion?  If so, is there documentation on what configuration needs
>>>>> to
>>>>>> happen to get this to work?
>>>>>> 
>>>>>> Thanks,
>>>>>> Doug
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 


Reply via email to