Dan, thanks for the response.

1) I changed it to https:// because at the time we took a snapshot this was
not working.  I suspect it DOES work now and I can revert it back.

2) We determined this is only going to be an issue for self-signed
certificates (in our QA environment).  We are guessing in real production a
valid signed certificate will be fine (we hope).

3) Ya, I'd love to know why it proxies to itself.

doug


On 10/19/11 2:54 PM, "Dan Dumont" <ddum...@us.ibm.com> wrote:

> Well..  you could try to set it to localhost and then provide custom
> values in the CommonContainer config.
> Wondering why you changed this to https:// instead of //
> 
> Starting a url with // should use the protocol being used by the page. was
> it not working for https in your case?
> 
> I'm not sure why shindig proxies to itself...  I'm sure there's some
> obscure reason :)
> 
> 
> 
> From:   daviesd <davi...@oclc.org>
> To:     <dev@shindig.apache.org>,
> Date:   10/19/2011 12:02 PM
> Subject:        Re: listMethods and https
> 
> 
> 
> *bump*
> 
> The last time I posted this message it didn¹t gain any traction.  However
> this is now affecting us in a production environment and forces us to
> import
> the certificate of the load balancer into our shindig server.  Ideas?
> 
> 
> On 6/1/11 3:33 PM, "Davies,Douglas" <davi...@oclc.org> wrote:
> 
>> Our shindig server runs under https.  It appears that the shindig server
> makes
>> a call back to itself for listMethods using
>> 
>>   "osapi" : {
>>     "endPoints" : [ "https://%host%/opensocial/rpc"; ]
>>   }
>> 
>> from container.js (which I¹ve overridden with https and our webcontext).
>> 
>> 1)      Why does shindig call back into itself and not just make a
> function
>> call?  Why doesn¹t it just use local host?  This requires the
> certificate to
>> be installed and java made aware of it.
>> 
>> 2)      Some of these values seem to be used client-side as well as
>> server-side.  If I remember right, when I changed it to
>> http://localhost/opensocial/rpc , then I had trouble client-side.
> Unfortunate
>> that the value is used for dual purposes.
> 
> 
> 
> 


Reply via email to