Hi Nuwan, I'm wondering if a servlet filter might be a possible solution to this problem. Since it sounds like everything is running under the same servlet container, I think you could just drop a servlet filter in front of any /gadgets/ifr requests and within the filter get access to the users current session -- then just do whatever checks you need to ensure that the current user is authorized to render the requested gadget, returning a 401 if they aren't. Then nothing on the shindig side needs to change and you can still take advantage of shindigs ability to cache previously fetched gadget specs.
Although as I think through this a little more -- it sounds like the gadget specs themselves might contain sensitive data -- and the scenario above assumes shindig has open access to the specs (since it wouldn't be sending along any user identifier when it fetches the spec). In that case maybe you could restrict access to the gadget specs to only allow access if the request originated from the gadget server directly? Hmm -- but then people could still get to them through shindigs various proxy mechanisms... So I guess I'm not really sure if this helps or not, but I thought it might at least give you some other ideas... --Jesse -----Original Message----- From: bandara.nu...@gmail.com [mailto:bandara.nu...@gmail.com] On Behalf Of Nuwan Bandara Sent: Wednesday, November 17, 2010 3:58 AM To: dev@shindig.apache.org Subject: Re: Session aware gadget xml fetching. Hi John, I have a solution for this problem, however when it comes to caching, it introduces a limitation. Let me elaborate on it. I have a container (Gadget Server), which wraps shindig to perform gadget rendering functionality. The server also provide a repository to store gadget and all other standard portal specific feature (users/roles etc). When a user login to the server, there will be an authenticated session created. but the issue is that shindig is not using this session. My solution is to delegate the browser cookie to shindig, where shindig will append this cookie to its request and perform the fetch. So at that point the container will have access to the authenticated session. but as I mentioned the tradeoff will be caching. For the gadgets which are hosted in the same container I cannot provide caching as an option. WDYT ? Thanks & Regards, /Nuwan On Wed, Nov 17, 2010 at 1:29 PM, John Hjelmstad <fa...@google.com> wrote: > Hi Nuwan: > > This is actually a somewhat common pattern, assuming I understand you > correctly. > > One question, how do you propose to get session information to the gadget > renderer in the first place? Typically the renderer is hosted on a jail > domain isolated from any container, so the security token is occasionally > used. > > Injection of some kind of Provider<SessionContext> is injected where this > evaluation is needed -- such as the HttpFetcher impl, and perhaps the > RequestPipeline as well to ensure that caching is consistent w/ whatever > policy you're implementing as well. > > --j > > On Tue, Nov 16, 2010 at 7:40 PM, Nuwan Bandara <bandara.nu...@gmail.com > >wrote: > > > Hi Devs, > > > > I am facing a difficulty, while using shindig to make session aware calls > > to > > fetch gadget xmls. My requirement is as follows. > > > > When shindig is running as the gadget renderer, and when there are > gadgets > > hosted in the same container, there should be a mechanism to use the > > current > > http session when fetching these gadget xmls. The requirement is, there > can > > be gadgets which are specific to some users (based on roles), and if the > > web > > application supports user/role based permissions, if shindig makes > session > > aware requests to the container, only the permitted gadgets can be > > retrieved > > from the container. > > > > I am aware this is not always the case where gadgets are taken from > > external > > locations, but if this is also supported in a configurable manner, I > > believe > > it would be quite useful. WDYT ? > > > > Regards, > > /Nuwan > > > -- Thanks & Regards, Nuwan Bandara - www.nuwanbando.com - Stranger Than Fiction [ http://www.linkedin.com/in/nuwanbandara ] [ http://www.twitter.com/nuwanbando ]
