On Mon, Jun 22, 2009 at 4:41 PM, Tim Moore <tmo...@atlassian.com> wrote:
> > On Jun 22, 2009, at 3:05 PM, Kevin Brown wrote: > > Since we've embedded Shindig in our webapps, we want its logging to go >>> into >>> our applications' logs. Most of our customers run our applications in a >>> dedicated Tomcat instance, but not all of them. We have some people who >>> load >>> several applications into one big fat Weblogic or WebSphere container. >>> Maybe >>> it's crazy, but it's something that we currently support. Unfortunately, >>> this makes VM-global configuration a problem, since if someone is >>> running, >>> say both JIRA & Confluence in one webapp, and they each embed a copy of >>> Shindig, configuring the Shindig loggers at the VM level is going to send >>> some messages to the wrong file. >>> >> >> >> I think you're going to have bigger problems than logging with this setup. >> How do you guarantee domain isolation? How can I be sure that the gadgets >> running in JIRA can't be attacked by gadgets running the confluence >> version? >> > > We don't guarantee domain isolation, and that risk is a trade-off we have > to make. This is why we make administrators white-list allowed gadgets. > We're trying to be very clear with our customers that gadgets running in our > containers should not be considered any safer than server-side plugins. We > have to assume that the administrators of one application trust the > administrators of any other applications running in the same container. If > that's not the case, then there are definitely far bigger problems that > could arise. Other than gadgets, server-side plugins could steal cookies. > > In practice, that's not usually a huge concern. The administrators are > nearly always the same people. > > So I'm writing the list to ask: >>> >>> 1. Does anyone have any other suggestions for a better way to handle >>> this? >>> >> >> Have you tried packaging shindig as a dedicated app rather than >> 'embedding' >> it? This might complicate your configuration a bit, but it would ensure >> that >> you had just one copy of shindig running, even if it serviced multiple >> containers (JIRA, confluence, etc.) >> > > It's something we have considered as an option for administrators who want > to trade the increased complexity for added security. Even if we do decide > to go that route, we really need to have a simple, single-WAR file > installation option, for evaluators if nobody else. We want something that > can start up and run with a minimum of configuration needed. That's how the > software has worked for years, and we'd really be very reluctant to change > that to enable gadget support. What about treating the gadget server the same way that you treat confluence or JIRA themselves? Instead of the 'embedding', just have a configuration option that points the products at the gadget server, if there is one. This would let you keep your existing deployment setup, and the only people who would have any extra work would be those who want to run gadgets. > > > Putting aside our deployment scenario for now, do you have any thoughts > specifically about the logging questions? I don't have any strong opinions on the matter. I have never encountered a situation where java.util.logging was inadequate. The performance kind of sucks due to excessive synchronization, but the API itself doesn't seem bad enough to bother with an external dependency. > > > -- Tim > > >
