Hi, A heads-up for such a scenario: If your gadget definitions are also on https servers, and they use user-preferences, there is an issue that Shindig currently tries to use gmodules.com to render the user prefs. However, gmodules does not support https :(
cheers, Niels On 01/17/2011 01:17 PM, Xandeco, Maxwell wrote: > 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 >>> >> >> > >
