[jira] Commented: (SHINDIG-379) Allow parameter adaption when requesting data from the container

["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.