Thanks Doug/John.

I revisited this and got it working.  In our case we do not build shindig from 
source.  We just pull down the maven artifacts and supply our own container.js. 
 I managed to find the correct values the get us up and running with https.  
The following are the container.js values I needed to override to get https to 
work.

"gadgets.jsUriTemplate" : "https://%host%/opensocial/gadgets/js/%js%";
"gadgets.uri.iframe.unlockedDomain" : "https://myhost";
"gadgets.uri.js.host" : "https://myhost";
"path" : "https://%host%/opensocial/rpc";
"invalidatePath" : "https://%host%/opensocial/rpc";
"endPoints" : [ "https://%host%/opensocial/rpc"; ]

No java code patched so far.  So apparently for my needs I'm not hitting the 
code paths you had to patch in java code.  We also run our shindig server on a 
different domain from the container client and a different web context 
(/opensocial), so we override some of those values in container.js as well. 

Thanks,
doug

-----Original Message-----
From: Doug Ellison [mailto:doug.elli...@gmail.com] 
Sent: Thursday, April 21, 2011 10:37 AM
To: Davies,Douglas
Cc: dev@shindig.apache.org; John Hjelmstad; Niels van Dijk
Subject: Re: HTTP / HTTPS question

So I think you've missed a point suggested by John.  There are certain
code paths that are simply not coded to be schema relative.  Meaning
certain parts of the code do not know the difference between http and
https.  You would need to implement those parts of the code that do
not support it at this time.  So unless I'm not taking your statement
of "I've tried most of the suggestions on this thread" to its full
conclusion meaning you have went in and implemented at least the one
portion that John mentioned for changing the code to be schema
relative.  Its just not going to work.  I don't know all the various
portions that need to be changed hence why I just did a find replace
all since my webapp it https only anways.

On Thu, Apr 21, 2011 at 7:48 AM, Davies,Douglas <davi...@oclc.org> wrote:
> I am hitting this issue as well. I've tried most of the suggestions on this 
> thread (except for the complete replacement of http for https).
>
> I had everything working great as http and had patched things to run as a 
> non-root webcontext (/opensocial).  The metadata call on the http version does
>
> POST http://myserver.org:8443/opensocial/rpc?st=-1%3A-1%3A*%3A%3A*%3A0%3Aoclc
>
> My https version does this at the same spot
>
> OPTIONS https://myserver.org:9443/api/rpc/cs?st=-1%3A-1%3A*%3A%3A*%3A0%3Aoclc
>
> And doesn't proceed any further.  Not sure why it's taking another path.  It 
> looks like I might need to patch service.js 
> (shindig.container.ServiceConfig.API_PATH).
>
> We will really need https support, so anyone that's gotten this to work 
> beyond the global search and replace I'd be interested to know what you did.
>
> Thanks,
> doug
>
>
>
> -----Original Message-----
> From: Doug Ellison [mailto:doug.elli...@gmail.com]
> Sent: Monday, March 28, 2011 4:42 PM
> To: John Hjelmstad
> Cc: Niels van Dijk; dev@shindig.apache.org
> Subject: Re: HTTP / HTTPS question
>
> So just thought I'd send this out to let people know where I went with
> this.  I didn't feel confident in my ability to write up a code patch
> to change everything from hard coded to relative but I did find a sort
> of "hacky" way around it.
> I did a full checkout of trunk and then ran the below command:
>  find . -exec grep -l 'http://[%]' {} \; | xargs sed -i
> 's/http:\/\/%/https:\/\/%/g'
> It breaks the tests which I'm then going to go back and work to fix
> but it does successfully take everything from http to https and the
> code "seems" to run just fine.  I realize this is not the best
> approach for everyone but this allowed me to do what I was wanting to
> do.
>
> Once again thank you soooooo much for the help John and everyone else
> who responded.
>
>
>
> On Fri, Mar 25, 2011 at 5:56 PM, John Hjelmstad <fa...@google.com> wrote:
>> That makes sense -- that's essentially what I mean when I say there are some
>> places where config and URL validation could use some cleanup to be
>> schema-agnostic. Best is schema-relative, but the difficulty w/ that is that
>> you need (in server code) to inject schema in various places.
>> --j
>>
>> On Fri, Mar 25, 2011 at 4:49 PM, Doug Ellison <doug.elli...@gmail.com>
>> wrote:
>>>
>>> I guess what I'm referring to for transitions is I access servlets from
>>> https and they are accessible.  But checking chrome javascript logs there
>>> are still references to http and those references are what seem to break.
>>> So transition is probably not the right word.  It doesn't always detect from
>>> where it came http or https and always use the correct pathing.  Does that
>>> make sense?  I guess I wilk try doing a replace all from http to https and
>>> see what happens.
>>>
>>> On Mar 25, 2011 5:37 PM, "John Hjelmstad" <fa...@google.com> wrote:
>>>
>>> You can still host gadgets on an HTTP server -- that's an orthogonal issue
>>> to the way that you access your Shindig-hosted server. Shindig acts as an
>>> HTTP client when fetching gadgets, and can fetch via HTTP or HTTPS.
>>> What do you refer to when you say http/https transitions? For the most
>>> part Shindig supports HTTPS -- we @ Google use it extensively for this
>>> purpose. But there are a few bits and pieces of config/verification around
>>> that look like they could use some cleanup in the "default" installation to
>>> ensure HTTP/HTTPS agnosticism.
>>> --j
>>>
>>> On Fri, Mar 25, 2011 at 4:27 PM, Doug Ellison <doug.elli...@gmail.com>
>>> wrote: > > Thanks for all t...
>>
>
>
>


Reply via email to