So why sometimes SecureToken is null on HttpRequest? Still looking for a way to wrap some cookies/header from original request, but looks like shindig ignores them, any advice here?
Does anyone has a objection about include in shindig a way to allow original cookies/parameters/header to be included in the shinding HttpRequest object? Thanks ________________________________________ De: Xandeco, Maxwell [[email protected]] Enviado: terça-feira, 18 de janeiro de 2011 11:26 Para: [email protected] Assunto: RES: Requesting Gadget Metadata from a Secured URL Hi, the issue mentioned in the link, it's pretty similar what I have now. I'm using shindig in a intranet, and external gadgets are not allowed, so I will not have "untrusted gadgets", every gadget must be accepted by "container owner/admin", and all will be in the intranet. I create a custom AuthenticationHandler and a custom SecurityToken based on AnonymousToken, in the handler I look for the cookie in the request, if I found then I create the new token and set the cookie value in a private variable, so I replaced the BasicHttpFetcher with a SecureHttpFetcher, and i was thinking to check the securityToken in the fetcher method and if has the cookie value, set the header in HTTP request, but I'm surprised now, always the fetch method is called the security token is null. Maxwell ________________________________________ De: Ciancetta, Jesse E. [[email protected]] Enviado: terça-feira, 18 de janeiro de 2011 10:57 Para: [email protected] Assunto: RE: Requesting Gadget Metadata from a Secured URL If there's nothing sensitive in the gadget specs that need authentication on a per user basis, you could probably just guice inject a custom extended version of the BasicHttpFetcher which overrides the fetch method and looks at the URI of the resource being fetched -- and if it's a request for a gadget spec under your well known gadget spec location, inject a set of service account credentials to satisfy the SSO authentication challenge. That's assuming requests for gadget specs go through the BasicHttpFetcher -- but I think they do if I recall. And that's also assuming that 3.0 still works the same way as 2.0 did -- I haven't looked at trunk in a while so I can't say for sure. BTW -- there was some discussion on this topic previously which might be helpful: http://www.mail-archive.com/[email protected]/msg02610.html As John mentions in his response in that thread, depending on your configuration it could be difficult to get access to the SSO tokens from the shindig side. 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. One way to work around these issues but still have SSO tokens available to send to shindig for trusted gadgets would be to render gadgets on two different domains -- rendering on your SSO domain for trusted gadgets and an untrusted jail domain for untrusted gadgets. On the backend you have a bunch of different options for how to service gadget requests on those domains, but the simplest approach might be to have two different instances of shindig running -- one for trusted gadgets and one for untrusted gadgets (which is nice because you can then have two completely different configurations for those shindig instances). Then on your container side, depending on if the gadget specs live in a well known trusted location (like anywhere on your trusted SSO domain) you can generate the rendering url for the appropriate domain. I realize I'm making assumptions here about your environment and getting a little off topic but I'm figuring this is probably all relevant if you're talking about SSO (I'm assuming your running inside of an enterprise). --Jesse -----Original Message----- From: Xandeco, Maxwell [mailto:[email protected]] Sent: Monday, January 17, 2011 7:18 AM To: [email protected] Subject: RES: Requesting Gadget Metadata from a Secured URL unfortunately it's not my choose, it's a requirement here, everything must be over a secure server with sso. Maxwell _______________________________________ De: Christiaan Hees [[email protected]] Enviado: segunda-feira, 17 de janeiro de 2011 8:35 Para: [email protected] Assunto: Re: Requesting Gadget Metadata from a Secured URL Why is your gadget spec xml behind SSO anyway? I think in general you should design your gadgets in a way so the spec can be public. On Sat, Jan 15, 2011 at 2:05 AM, Ryan J Baxter <[email protected]> wrote: > So the server Shindig is running on does not require the user to log on? > Why not for the user to log on when accessing the server running Shindig > as well? That way when to access other URLs that require to log in, there > won't be a problem. > > -Ryan > > Email: [email protected] > Phone: 978-899-3041 > developerWorks Profile > > > > From: Maxwell <[email protected]> > To: [email protected] > Date: 01/14/2011 06:33 PM > Subject: Re: Requesting Gadget Metadata from a Secured URL > > > > The domain does not matter here, look I my server has a sso project, that > handles all projects in the server, pretty normal stuff here, when i call > any url for the first time, my server see that i'm not authenticated, so > execute the login action, after that all browser request goes with a > cookie > (sso cookie), that is also pretty normal, if I try to access my xml spec > over a secured url using the browser i can see the file, because the > browser > is authenticated and send the cookie, everything is fine here. > > When I ask to shindig render a gadget to me, it does a request, at this > moment it's not a user request (browser request). shindig does another > request, and do not pass the original user request object > (servletRequest), > so my server does not allow shindig to access the resource (xml). > > So I'm trying to figure out a way to do that, but for what i see, i have > to > rewrite all "call chain" pf the request, from the Servlet to the > HttpFetcher > to allow pass original request through. > > Why shindig assume that all server is public? > > Imagine that igoogle do not let you to see and get the gadgets spec, > unless > your logged with your account and pass some cookie to it, how you are > going > to do that? > > > Thanks. > > On Fri, Jan 14, 2011 at 9:20 PM, Henry Saputra > <[email protected]>wrote: > >> Hmmm are you saying that Shindig is put in different domain/ url so >> the request come from client will go to different URL without cookie? >> >> - Henry >> >> On Wed, Jan 5, 2011 at 10:09 AM, Xandeco, Maxwell >> <[email protected]> wrote: >> > >> > Hi guys, >> > >> > We have to use a SSO secured server, that means all apps in the > container >> will be covered by the SSO system, even the gadgets spec XML. >> > >> > My server uses a user cookie sent by browser to authorize the access, >> it's a simple SSO system, the add/render gadget flow it's basically: >> > >> > Browser --> RpcServlet --> JSONRpcHandler --> Processor --> >> GadgetSpecFactory --> RequestPipeline --> HttpFetcher >> > >> > Shindig does a new request, with any association with the original > client >> request (that has all cookies necessary to pass over security handlers), >> it's just like try access a url without login, so i got a 401 error, > it's >> pretty easy to replace implementations on shindig using google-guice, > but >> the only way i see here, is rewritten all classes involved in the > process, >> because after JSONRpcHandler the original request it's not passed > through. >> > >> > How do you guys normally handle that, you always put spec in public > urls? >> > >> > Cheers. >> > >> >> >> >> -- >> Thanks, >> Henry >> > > > >
