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