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
