You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Henning Schmiedehausen (JIRA)" <ji...@apache.org> on 2008/06/12 01:34:45 UTC
[jira] Created: (SHINDIG-379) Allow parameter adaption when
requesting data from the container
Allow parameter adaption when requesting data from the container
----------------------------------------------------------------
Key: SHINDIG-379
URL: https://issues.apache.org/jira/browse/SHINDIG-379
Project: Shindig
Issue Type: New Feature
Components: Gadget Rendering Server (Java)
Reporter: Henning Schmiedehausen
Attachments: security-decoder.patch
The current Shindig code base allows only a single parameter (the secure token) to be passed from the javascript to the GadgetDataServlet. This is hard coded in the GadgetDataServlet::doPost method by pulling the st parameter from the HttpRequestObject and then calling createResponse with this parameter.
In our specific environment, we need to pass multiple parameters, mainly because we want to treat the security token as completely opaque to the Java container because our social data is stored per domain and we have implementations of the various service interfaces that know how to access these stores. So we just hand out the token that was created per domain to the stores. To select a store, we need one additional parameter, namely the domain to select the store.
The attached patch adds an adapter to the GadgetDataServlet, that allows passing of an arbitrary set of parameters. There is a default implementation which transfers the secure token and the request parameter (just as the hard coded implementation did). This gave us enough flexibility to pass additional parameters to the createResponse method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-379) Allow parameter adaption when
requesting data from the container
Posted by "Brian McCallister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607672#action_12607672 ]
Brian McCallister commented on SHINDIG-379:
-------------------------------------------
I'm going to go ahead and apply this -- if we come up with a better way we can always change it :-)
> Allow parameter adaption when requesting data from the container
> ----------------------------------------------------------------
>
> Key: SHINDIG-379
> URL: https://issues.apache.org/jira/browse/SHINDIG-379
> Project: Shindig
> Issue Type: New Feature
> Components: Gadget Rendering Server (Java)
> Reporter: Henning Schmiedehausen
> Assignee: Brian McCallister
> Attachments: security-decoder.patch
>
>
> The current Shindig code base allows only a single parameter (the secure token) to be passed from the javascript to the GadgetDataServlet. This is hard coded in the GadgetDataServlet::doPost method by pulling the st parameter from the HttpRequestObject and then calling createResponse with this parameter.
> In our specific environment, we need to pass multiple parameters, mainly because we want to treat the security token as completely opaque to the Java container because our social data is stored per domain and we have implementations of the various service interfaces that know how to access these stores. So we just hand out the token that was created per domain to the stores. To select a store, we need one additional parameter, namely the domain to select the store.
> The attached patch adds an adapter to the GadgetDataServlet, that allows passing of an arbitrary set of parameters. There is a default implementation which transfers the secure token and the request parameter (just as the hard coded implementation did). This gave us enough flexibility to pass additional parameters to the createResponse method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHINDIG-379) Allow parameter adaption when
requesting data from the container
Posted by "Henning Schmiedehausen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henning Schmiedehausen updated SHINDIG-379:
-------------------------------------------
Attachment: security-decoder-2.patch
this is an updated patch against the current HEAD.
> Allow parameter adaption when requesting data from the container
> ----------------------------------------------------------------
>
> Key: SHINDIG-379
> URL: https://issues.apache.org/jira/browse/SHINDIG-379
> Project: Shindig
> Issue Type: New Feature
> Components: Gadget Rendering Server (Java)
> Reporter: Henning Schmiedehausen
> Assignee: Brian McCallister
> Attachments: security-decoder-2.patch, security-decoder.patch
>
>
> The current Shindig code base allows only a single parameter (the secure token) to be passed from the javascript to the GadgetDataServlet. This is hard coded in the GadgetDataServlet::doPost method by pulling the st parameter from the HttpRequestObject and then calling createResponse with this parameter.
> In our specific environment, we need to pass multiple parameters, mainly because we want to treat the security token as completely opaque to the Java container because our social data is stored per domain and we have implementations of the various service interfaces that know how to access these stores. So we just hand out the token that was created per domain to the stores. To select a store, we need one additional parameter, namely the domain to select the store.
> The attached patch adds an adapter to the GadgetDataServlet, that allows passing of an arbitrary set of parameters. There is a default implementation which transfers the secure token and the request parameter (just as the hard coded implementation did). This gave us enough flexibility to pass additional parameters to the createResponse method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-379) Allow parameter adaption when
requesting data from the container
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604398#action_12604398 ]
Kevin Brown commented on SHINDIG-379:
-------------------------------------
s/may/do :)
It's certainly something we need for the google deployment as well.
> Allow parameter adaption when requesting data from the container
> ----------------------------------------------------------------
>
> Key: SHINDIG-379
> URL: https://issues.apache.org/jira/browse/SHINDIG-379
> Project: Shindig
> Issue Type: New Feature
> Components: Gadget Rendering Server (Java)
> Reporter: Henning Schmiedehausen
> Attachments: security-decoder.patch
>
>
> The current Shindig code base allows only a single parameter (the secure token) to be passed from the javascript to the GadgetDataServlet. This is hard coded in the GadgetDataServlet::doPost method by pulling the st parameter from the HttpRequestObject and then calling createResponse with this parameter.
> In our specific environment, we need to pass multiple parameters, mainly because we want to treat the security token as completely opaque to the Java container because our social data is stored per domain and we have implementations of the various service interfaces that know how to access these stores. So we just hand out the token that was created per domain to the stores. To select a store, we need one additional parameter, namely the domain to select the store.
> The attached patch adds an adapter to the GadgetDataServlet, that allows passing of an arbitrary set of parameters. There is a default implementation which transfers the secure token and the request parameter (just as the hard coded implementation did). This gave us enough flexibility to pass additional parameters to the createResponse method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-379) Allow parameter adaption when
requesting data from the container
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605882#action_12605882 ]
Kevin Brown commented on SHINDIG-379:
-------------------------------------
I'll leave the decision on the best way to proceed with this to the people actively working on the social-api artifact -- Cassie?
> Allow parameter adaption when requesting data from the container
> ----------------------------------------------------------------
>
> Key: SHINDIG-379
> URL: https://issues.apache.org/jira/browse/SHINDIG-379
> Project: Shindig
> Issue Type: New Feature
> Components: Gadget Rendering Server (Java)
> Reporter: Henning Schmiedehausen
> Attachments: security-decoder.patch
>
>
> The current Shindig code base allows only a single parameter (the secure token) to be passed from the javascript to the GadgetDataServlet. This is hard coded in the GadgetDataServlet::doPost method by pulling the st parameter from the HttpRequestObject and then calling createResponse with this parameter.
> In our specific environment, we need to pass multiple parameters, mainly because we want to treat the security token as completely opaque to the Java container because our social data is stored per domain and we have implementations of the various service interfaces that know how to access these stores. So we just hand out the token that was created per domain to the stores. To select a store, we need one additional parameter, namely the domain to select the store.
> The attached patch adds an adapter to the GadgetDataServlet, that allows passing of an arbitrary set of parameters. There is a default implementation which transfers the secure token and the request parameter (just as the hard coded implementation did). This gave us enough flexibility to pass additional parameters to the createResponse method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-379) Allow parameter adaption when
requesting data from the container
Posted by "Henning Schmiedehausen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605878#action_12605878 ]
Henning Schmiedehausen commented on SHINDIG-379:
------------------------------------------------
Any move forward on this? Apart from the comment "we need this", I haven't heard much back.
> Allow parameter adaption when requesting data from the container
> ----------------------------------------------------------------
>
> Key: SHINDIG-379
> URL: https://issues.apache.org/jira/browse/SHINDIG-379
> Project: Shindig
> Issue Type: New Feature
> Components: Gadget Rendering Server (Java)
> Reporter: Henning Schmiedehausen
> Attachments: security-decoder.patch
>
>
> The current Shindig code base allows only a single parameter (the secure token) to be passed from the javascript to the GadgetDataServlet. This is hard coded in the GadgetDataServlet::doPost method by pulling the st parameter from the HttpRequestObject and then calling createResponse with this parameter.
> In our specific environment, we need to pass multiple parameters, mainly because we want to treat the security token as completely opaque to the Java container because our social data is stored per domain and we have implementations of the various service interfaces that know how to access these stores. So we just hand out the token that was created per domain to the stores. To select a store, we need one additional parameter, namely the domain to select the store.
> The attached patch adds an adapter to the GadgetDataServlet, that allows passing of an arbitrary set of parameters. There is a default implementation which transfers the secure token and the request parameter (just as the hard coded implementation did). This gave us enough flexibility to pass additional parameters to the createResponse method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHINDIG-379) Allow parameter adaption when
requesting data from the container
Posted by "Henning Schmiedehausen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henning Schmiedehausen updated SHINDIG-379:
-------------------------------------------
Attachment: security-decoder.patch
> Allow parameter adaption when requesting data from the container
> ----------------------------------------------------------------
>
> Key: SHINDIG-379
> URL: https://issues.apache.org/jira/browse/SHINDIG-379
> Project: Shindig
> Issue Type: New Feature
> Components: Gadget Rendering Server (Java)
> Reporter: Henning Schmiedehausen
> Attachments: security-decoder.patch
>
>
> The current Shindig code base allows only a single parameter (the secure token) to be passed from the javascript to the GadgetDataServlet. This is hard coded in the GadgetDataServlet::doPost method by pulling the st parameter from the HttpRequestObject and then calling createResponse with this parameter.
> In our specific environment, we need to pass multiple parameters, mainly because we want to treat the security token as completely opaque to the Java container because our social data is stored per domain and we have implementations of the various service interfaces that know how to access these stores. So we just hand out the token that was created per domain to the stores. To select a store, we need one additional parameter, namely the domain to select the store.
> The attached patch adds an adapter to the GadgetDataServlet, that allows passing of an arbitrary set of parameters. There is a default implementation which transfers the secure token and the request parameter (just as the hard coded implementation did). This gave us enough flexibility to pass additional parameters to the createResponse method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-379) Allow parameter adaption when
requesting data from the container
Posted by "David Primmer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604393#action_12604393 ]
David Primmer commented on SHINDIG-379:
---------------------------------------
This is an interesting problem that many other containers may have. When I've asked about it in the past, it was assumed that some trusted source would peek at the token and get the container out of the token and then do routing based on that. Another approach was to look at the domain (or some other path segment) that the api server was running on and make a dispatch to the proper handler, without peeking in the token (letting the container verify that the request was for them). You could combine these two of course.
I would support a servlet filter being added to shindig that allowed one to add this container destination info to the context. It is one of many things that could be used to make a dispatch decision. You may want to filter certain operations per container at this level. Also, it should be combined with the signed fetch and oauth processing code that is coming.
What other params are you adding besides the container id?
> Allow parameter adaption when requesting data from the container
> ----------------------------------------------------------------
>
> Key: SHINDIG-379
> URL: https://issues.apache.org/jira/browse/SHINDIG-379
> Project: Shindig
> Issue Type: New Feature
> Components: Gadget Rendering Server (Java)
> Reporter: Henning Schmiedehausen
> Attachments: security-decoder.patch
>
>
> The current Shindig code base allows only a single parameter (the secure token) to be passed from the javascript to the GadgetDataServlet. This is hard coded in the GadgetDataServlet::doPost method by pulling the st parameter from the HttpRequestObject and then calling createResponse with this parameter.
> In our specific environment, we need to pass multiple parameters, mainly because we want to treat the security token as completely opaque to the Java container because our social data is stored per domain and we have implementations of the various service interfaces that know how to access these stores. So we just hand out the token that was created per domain to the stores. To select a store, we need one additional parameter, namely the domain to select the store.
> The attached patch adds an adapter to the GadgetDataServlet, that allows passing of an arbitrary set of parameters. There is a default implementation which transfers the secure token and the request parameter (just as the hard coded implementation did). This gave us enough flexibility to pass additional parameters to the createResponse method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-379) Allow parameter adaption when
requesting data from the container
Posted by "Henning Schmiedehausen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604418#action_12604418 ]
Henning Schmiedehausen commented on SHINDIG-379:
------------------------------------------------
BTW: We actually use only a single container, not multiple. This would make no sense in our environment, because all the rendering etc. of the Gadgets is centralized anyway.
I don't understand how you would use a ServletFilter to do this dispatching. Could you elaborate a bit?
For us, the token is intended to be opaque in the Java part of our server. The implementations of PersonService, ActivityService and AppDataService access the backends through an internal API. The dispatching to which backend happens through this additional parameter. The backends do validate the contents of the token (they can decrypt it) and validate whether the request hits the right backend (as the dispatch value could obviously be forged.
> Allow parameter adaption when requesting data from the container
> ----------------------------------------------------------------
>
> Key: SHINDIG-379
> URL: https://issues.apache.org/jira/browse/SHINDIG-379
> Project: Shindig
> Issue Type: New Feature
> Components: Gadget Rendering Server (Java)
> Reporter: Henning Schmiedehausen
> Attachments: security-decoder.patch
>
>
> The current Shindig code base allows only a single parameter (the secure token) to be passed from the javascript to the GadgetDataServlet. This is hard coded in the GadgetDataServlet::doPost method by pulling the st parameter from the HttpRequestObject and then calling createResponse with this parameter.
> In our specific environment, we need to pass multiple parameters, mainly because we want to treat the security token as completely opaque to the Java container because our social data is stored per domain and we have implementations of the various service interfaces that know how to access these stores. So we just hand out the token that was created per domain to the stores. To select a store, we need one additional parameter, namely the domain to select the store.
> The attached patch adds an adapter to the GadgetDataServlet, that allows passing of an arbitrary set of parameters. There is a default implementation which transfers the secure token and the request parameter (just as the hard coded implementation did). This gave us enough flexibility to pass additional parameters to the createResponse method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-379) Allow parameter adaption when
requesting data from the container
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604391#action_12604391 ]
Kevin Brown commented on SHINDIG-379:
-------------------------------------
"In our specific environment, we need to pass multiple parameters, mainly because we want to treat the security token as completely opaque to the Java container because our social data is stored per domain and we have implementations of the various service interfaces that know how to access these stores. So we just hand out the token that was created per domain to the stores. To select a store, we need one additional parameter, namely the domain to select the store."
This is why the Gadget renderer supports multiple containers (and the motivation for ContainerConfig.java). Many deployments of Shindig require multiple containers to be supported by the same parent.
Really, the social-api should be doing the same thing. The lessons we learned doing gadget rendering shouldn't be forgotten for accessing social data.
> Allow parameter adaption when requesting data from the container
> ----------------------------------------------------------------
>
> Key: SHINDIG-379
> URL: https://issues.apache.org/jira/browse/SHINDIG-379
> Project: Shindig
> Issue Type: New Feature
> Components: Gadget Rendering Server (Java)
> Reporter: Henning Schmiedehausen
> Attachments: security-decoder.patch
>
>
> The current Shindig code base allows only a single parameter (the secure token) to be passed from the javascript to the GadgetDataServlet. This is hard coded in the GadgetDataServlet::doPost method by pulling the st parameter from the HttpRequestObject and then calling createResponse with this parameter.
> In our specific environment, we need to pass multiple parameters, mainly because we want to treat the security token as completely opaque to the Java container because our social data is stored per domain and we have implementations of the various service interfaces that know how to access these stores. So we just hand out the token that was created per domain to the stores. To select a store, we need one additional parameter, namely the domain to select the store.
> The attached patch adds an adapter to the GadgetDataServlet, that allows passing of an arbitrary set of parameters. There is a default implementation which transfers the secure token and the request parameter (just as the hard coded implementation did). This gave us enough flexibility to pass additional parameters to the createResponse method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SHINDIG-379) Allow parameter adaption when
requesting data from the container
Posted by "Brian McCallister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian McCallister resolved SHINDIG-379.
---------------------------------------
Resolution: Fixed
Applied to trunk in r671387
> Allow parameter adaption when requesting data from the container
> ----------------------------------------------------------------
>
> Key: SHINDIG-379
> URL: https://issues.apache.org/jira/browse/SHINDIG-379
> Project: Shindig
> Issue Type: New Feature
> Components: Gadget Rendering Server (Java)
> Reporter: Henning Schmiedehausen
> Assignee: Brian McCallister
> Attachments: security-decoder-2.patch, security-decoder.patch
>
>
> The current Shindig code base allows only a single parameter (the secure token) to be passed from the javascript to the GadgetDataServlet. This is hard coded in the GadgetDataServlet::doPost method by pulling the st parameter from the HttpRequestObject and then calling createResponse with this parameter.
> In our specific environment, we need to pass multiple parameters, mainly because we want to treat the security token as completely opaque to the Java container because our social data is stored per domain and we have implementations of the various service interfaces that know how to access these stores. So we just hand out the token that was created per domain to the stores. To select a store, we need one additional parameter, namely the domain to select the store.
> The attached patch adds an adapter to the GadgetDataServlet, that allows passing of an arbitrary set of parameters. There is a default implementation which transfers the secure token and the request parameter (just as the hard coded implementation did). This gave us enough flexibility to pass additional parameters to the createResponse method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-379) Allow parameter adaption when
requesting data from the container
Posted by "Henning Schmiedehausen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604414#action_12604414 ]
Henning Schmiedehausen commented on SHINDIG-379:
------------------------------------------------
we pass in a second parameter which selects our backend. The adapter implementation for ParameterFetcher extends the Default Fetcher and adds this parameter to the Map. It is basically
public class MyParameterFetcher extends GadgetDataServletFetcher {
public Map<String, String> fetch(HttpServletRequest req) {
Map<String, String> res = super.fetch(req);
res.put("mapkey", req.getParameter("additional_parameter_name");
return res;
}
}
and our SecurityToken implementation is then based off these multiple parameters.
> Allow parameter adaption when requesting data from the container
> ----------------------------------------------------------------
>
> Key: SHINDIG-379
> URL: https://issues.apache.org/jira/browse/SHINDIG-379
> Project: Shindig
> Issue Type: New Feature
> Components: Gadget Rendering Server (Java)
> Reporter: Henning Schmiedehausen
> Attachments: security-decoder.patch
>
>
> The current Shindig code base allows only a single parameter (the secure token) to be passed from the javascript to the GadgetDataServlet. This is hard coded in the GadgetDataServlet::doPost method by pulling the st parameter from the HttpRequestObject and then calling createResponse with this parameter.
> In our specific environment, we need to pass multiple parameters, mainly because we want to treat the security token as completely opaque to the Java container because our social data is stored per domain and we have implementations of the various service interfaces that know how to access these stores. So we just hand out the token that was created per domain to the stores. To select a store, we need one additional parameter, namely the domain to select the store.
> The attached patch adds an adapter to the GadgetDataServlet, that allows passing of an arbitrary set of parameters. There is a default implementation which transfers the secure token and the request parameter (just as the hard coded implementation did). This gave us enough flexibility to pass additional parameters to the createResponse method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SHINDIG-379) Allow parameter adaption when
requesting data from the container
Posted by "Brian McCallister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian McCallister reassigned SHINDIG-379:
-----------------------------------------
Assignee: Brian McCallister
> Allow parameter adaption when requesting data from the container
> ----------------------------------------------------------------
>
> Key: SHINDIG-379
> URL: https://issues.apache.org/jira/browse/SHINDIG-379
> Project: Shindig
> Issue Type: New Feature
> Components: Gadget Rendering Server (Java)
> Reporter: Henning Schmiedehausen
> Assignee: Brian McCallister
> Attachments: security-decoder.patch
>
>
> The current Shindig code base allows only a single parameter (the secure token) to be passed from the javascript to the GadgetDataServlet. This is hard coded in the GadgetDataServlet::doPost method by pulling the st parameter from the HttpRequestObject and then calling createResponse with this parameter.
> In our specific environment, we need to pass multiple parameters, mainly because we want to treat the security token as completely opaque to the Java container because our social data is stored per domain and we have implementations of the various service interfaces that know how to access these stores. So we just hand out the token that was created per domain to the stores. To select a store, we need one additional parameter, namely the domain to select the store.
> The attached patch adds an adapter to the GadgetDataServlet, that allows passing of an arbitrary set of parameters. There is a default implementation which transfers the secure token and the request parameter (just as the hard coded implementation did). This gave us enough flexibility to pass additional parameters to the createResponse method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.