This is right on time. We had similar issues with context root and host
port settings. We have developed a patch based on trunk and will be posting
for code review in a day or two.

Thanks and regards

Kris Vishwanathan, PMP
IBM Certified IT Architect
The Open Group Master Certified IT Architect
IBM Software Group, WPLC
Ph: 919 543 1081 (T/L: 441-1081)
Ph; 877-316-0046 (T/L: 349-4847)
Cell: 919 830 2890

If I had one hour to save the world I would spend fifty-five minutes
defining the problem and only five minutes finding the solution - Albert
Einstein




|------------>
| From:      |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------|
  |"Ciancetta, Jesse E." <[email protected]>                                      
                                                               |
  
>--------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------|
  |"[email protected]" <[email protected]>                            
                                                               |
  
>--------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------|
  |03/28/2011 09:05 AM                                                          
                                                               |
  
>--------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------|
  |RE: Root webapp???                                                           
                                                               |
  
>--------------------------------------------------------------------------------------------------------------------------------------------|





Comments inline below.

>-----Original Message-----
>From: daviesd [mailto:[email protected]]
>Sent: Sunday, March 27, 2011 10:44 AM
>To: [email protected]
>Subject: Root webapp???
>
>Hello. I¹m new to this listserv, so please correct any
>protocol/etiquette
>mistakes I might make.
>
>I¹m pretty new to opensocial and shindig.  I¹ve played around with
>bringing
>the war file down and renaming it ROOT.war.  I¹ve also played around
>with
>creating a new webapp application archetype and just pulling down the
>maven
>artifacts.  The issue I¹m struggling with (and I¹ve seen references to
>it on
>this group) is the root web app v.s. non-root webapp approach.  It would
>appear to me that since through 1.0, 2.0, and now 3.0 the root
>deployment
>nature of shindig hasn¹t changed, that this is the desired approach.
>However I see many references to people patching container.js and
>shindig.properties to get it to run in a different web context.  I would
>think the later is the more common case, but I might be missing
>something.
>The fact that there isn¹t just 1 location to change the context (and
>besides
>the fact that localhost is referenced all over the place) steers me into
>thinking the architects did not intend for this scenario however.  But
>then
>again, this is a reference implementation for us to change as required.

I don't think I'd say the architects didn't intend for the non-root
scenario -- I think it's likely just not something that was at the top of
anyone's list when the code was written initially.  I think everyone would
generally agree that having an easier way to deploy to a non-root context
would be a good thing.  And I'm also guessing the community would be happy
to accept a patch that makes that easier.  :-)

>
>Then a co-worker pointed me to this article
>
>http://www.freesoftwaremagazine.com/columns/opensocial_overview_how_open
>soci
>al_works_and_integrate_with_cms
>
>And asked if I inferred from this that the javascript container code
>should
>be installed on one server while the shindig server should be installed
>on
>another (for security reasons???).  My thought was is I¹d build a

You do generally want everything to be running on its own unique domain for
security purposes -- here's a cut and paste of some comments I made around
this on another thread a while back:

"Typically gadgets are rendered on a jail domain specifically to prevent
things like SSO cookies from being available to gadgets. Consider the
scenario where you are rendering an untrusted gadget from the internet --
if that gadget is rendered on the same domain as your SSO protected
container there is nothing stopping it from dipping into the browsers
cookie jar and grabbing your SSO cookies and then sending them off to some
third party via something like a makeRequest or a dynamic script tag
written to the page with the cookie values appended as parameters etc...
There are also issues with makeRequest -- you wouldn't want untrusted
gadgets sending makeRequests for resources behind your firewall and then
sending more makeRequests to post them out to some third party on the
internet."

Taken from here:

http://markmail.org/message/6mruilz4ll6i3ttk

You could also try searching the archives of the Shindig mailing lists for
"jail domain" and probably come up with some other good information on this
topic.

>shindig.war that was specific to our needs and allow anyone to drop this
>into there current environment.  I was envisioning it on the same host
>so
>that the javascript and server were both deployed together and the
>webapp
>could just reference /shindig/gadgets, etc.  All the hosting webapp
>would
>have to do is define the DIV elements that want to render into and
>provide
>some database setup for persistence.  What is the drawback of this
>approach?
>What is the preferred approach?  I hope this makes sense.
>
>One other thing... If anyone is aware of consultants/contractors that
>are
>shindig experts, I¹d be interested in talking to them about a possible
>stint
>at our company to help steer us in the right direction.
>
>Thanks,
>
>Doug Davies
>OCLC, Online Computer Library Catalog



Reply via email to