Hi Jesse, Thanks for your idea, however, I dont think it can solve the issue I am facing, let me explain a little
On Wed, Nov 17, 2010 at 7:19 PM, Ciancetta, Jesse E. <[email protected]>wrote: > 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. > Yes, you can front a servlet filter, and do the validation. But Assume User-A passes the validation and that he can access the gadget spec, and once it passes the filter and do the fetch via shindig (via shindigs networkFetch), my back-end gadget spec serving servlet doesn't know that the request is coming from User-A, since shindig doesn't have the logged-in session details to pass with the request. So at that point shindig cannot access my gadget spec, since its restricted to anonymous requests. > > 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... > Again thanks for your suggestion, The only solution I see is to pass the browser session cookie along with the request, but I wanted to know if there are any other solutions. Thanks & Regards, /Nuwan > > --Jesse > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Nuwan Bandara > Sent: Wednesday, November 17, 2010 3:58 AM > To: [email protected] > 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 <[email protected]> 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 <[email protected] > > >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 ] > -- Thanks & Regards, Nuwan Bandara - www.nuwanbando.com - Stranger Than Fiction [ http://www.linkedin.com/in/nuwanbandara ] [ http://www.twitter.com/nuwanbando ]
