Hi Guys, I feel there is an advantage of this feature to shindig, If so I would like to contribute my solution (if it is accepted as a viable one) as a patch, so shindig users who need such functionality can add few configuration and leverage the benefit.
Thanks & Regards, /Nuwan On Wed, Nov 17, 2010 at 7:41 PM, Nuwan Bandara <nu...@bandara.co> wrote: > 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. <jc...@mitre.org>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: 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 ] >> > > > > -- > 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 ]
