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