You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Xandeco, Maxwell" <Ma...@gft.com> on 2011/01/05 19:09:17 UTC
Requesting Gadget Metadata from a Secured URL
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.
Re: Requesting Gadget Metadata from a Secured URL
Posted by Maxwell <mc...@gmail.com>.
is everyone using xml over a public url? without any authentication?
On Wed, Jan 5, 2011 at 4:09 PM, Xandeco, Maxwell <Ma...@gft.com>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.
>
RES: Requesting Gadget Metadata from a Secured URL
Posted by "Xandeco, Maxwell" <Ma...@gft.com>.
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 [Maxwell.Xandeco@gft.com]
Enviado: terça-feira, 18 de janeiro de 2011 11:26
Para: dev@shindig.apache.org
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. [jcian@mitre.org]
Enviado: terça-feira, 18 de janeiro de 2011 10:57
Para: dev@shindig.apache.org
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/dev@shindig.apache.org/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:Maxwell.Xandeco@gft.com]
Sent: Monday, January 17, 2011 7:18 AM
To: dev@shindig.apache.org
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 [christiaan@q42.nl]
Enviado: segunda-feira, 17 de janeiro de 2011 8:35
Para: dev@shindig.apache.org
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 <rj...@us.ibm.com> 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: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: Maxwell <mc...@gmail.com>
> To: dev@shindig.apache.org
> 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
> <he...@gmail.com>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
>> <Ma...@gft.com> 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
>>
>
>
>
>
RES: Requesting Gadget Metadata from a Secured URL
Posted by "Xandeco, Maxwell" <Ma...@gft.com>.
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. [jcian@mitre.org]
Enviado: terça-feira, 18 de janeiro de 2011 10:57
Para: dev@shindig.apache.org
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/dev@shindig.apache.org/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:Maxwell.Xandeco@gft.com]
Sent: Monday, January 17, 2011 7:18 AM
To: dev@shindig.apache.org
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 [christiaan@q42.nl]
Enviado: segunda-feira, 17 de janeiro de 2011 8:35
Para: dev@shindig.apache.org
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 <rj...@us.ibm.com> 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: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: Maxwell <mc...@gmail.com>
> To: dev@shindig.apache.org
> 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
> <he...@gmail.com>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
>> <Ma...@gft.com> 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
>>
>
>
>
>
RE: Requesting Gadget Metadata from a Secured URL
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
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/dev@shindig.apache.org/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:Maxwell.Xandeco@gft.com]
Sent: Monday, January 17, 2011 7:18 AM
To: dev@shindig.apache.org
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 [christiaan@q42.nl]
Enviado: segunda-feira, 17 de janeiro de 2011 8:35
Para: dev@shindig.apache.org
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 <rj...@us.ibm.com> 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: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: Maxwell <mc...@gmail.com>
> To: dev@shindig.apache.org
> 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
> <he...@gmail.com>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
>> <Ma...@gft.com> 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
>>
>
>
>
>
Re: RES: Requesting Gadget Metadata from a Secured URL
Posted by Niels van Dijk <ni...@surfnet.nl>.
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 [christiaan@q42.nl]
> Enviado: segunda-feira, 17 de janeiro de 2011 8:35
> Para: dev@shindig.apache.org
> 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 <rj...@us.ibm.com> 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: rjbaxter@us.ibm.com
>> Phone: 978-899-3041
>> developerWorks Profile
>>
>>
>>
>> From: Maxwell <mc...@gmail.com>
>> To: dev@shindig.apache.org
>> 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
>> <he...@gmail.com>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
>>> <Ma...@gft.com> 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
>>>
>>
>>
> >
RES: Requesting Gadget Metadata from a Secured URL
Posted by "Xandeco, Maxwell" <Ma...@gft.com>.
unfortunately it's not my choose, it's a requirement here, everything must be over a secure server with sso.
Maxwell
_______________________________________
De: Christiaan Hees [christiaan@q42.nl]
Enviado: segunda-feira, 17 de janeiro de 2011 8:35
Para: dev@shindig.apache.org
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 <rj...@us.ibm.com> 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: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: Maxwell <mc...@gmail.com>
> To: dev@shindig.apache.org
> 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
> <he...@gmail.com>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
>> <Ma...@gft.com> 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
>>
>
>
>
>
Re: Requesting Gadget Metadata from a Secured URL
Posted by Christiaan Hees <ch...@q42.nl>.
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 <rj...@us.ibm.com> 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: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: Maxwell <mc...@gmail.com>
> To: dev@shindig.apache.org
> 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
> <he...@gmail.com>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
>> <Ma...@gft.com> 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
>>
>
>
>
>
RES: Requesting Gadget Metadata from a Secured URL
Posted by "Xandeco, Maxwell" <Ma...@gft.com>.
Shindig is running on a sso enabled server, but does not matter if user is logged or not, because shindig does another request to retrieve the xml file, and has no connection with the urrent user request.
Maxwell
________________________________________
De: Ryan J Baxter [rjbaxter@us.ibm.com]
Enviado: sexta-feira, 14 de janeiro de 2011 23:05
Para: dev@shindig.apache.org
Assunto: Re: Requesting Gadget Metadata from a Secured URL
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: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Maxwell <mc...@gmail.com>
To: dev@shindig.apache.org
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
<he...@gmail.com>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
> <Ma...@gft.com> 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
>
Re: Requesting Gadget Metadata from a Secured URL
Posted by Ryan J Baxter <rj...@us.ibm.com>.
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: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Maxwell <mc...@gmail.com>
To: dev@shindig.apache.org
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
<he...@gmail.com>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
> <Ma...@gft.com> 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
>
Re: Requesting Gadget Metadata from a Secured URL
Posted by Maxwell <mc...@gmail.com>.
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 <he...@gmail.com>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
> <Ma...@gft.com> 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
>
Re: Requesting Gadget Metadata from a Secured URL
Posted by Henry Saputra <he...@gmail.com>.
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
<Ma...@gft.com> 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