[
https://issues.apache.org/jira/browse/SHINDIG-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086514#comment-13086514
]
Jesse Ciancetta commented on SHINDIG-1580:
------------------------------------------
Hi Henry,
It could very well be me who is missing something! :-) I'll do my best to try
to explain our use case -- if you have any other ideas of how we could be doing
things differently please let me know.
We're actually generating our own security tokens in Rave on the server side
and then pushing those down into the common container via the preload mechanism
-- however we currently don't have any way to have the common container call
back to our custom server side code to do the refresh which is what this patch
starts to address.
We want to generate/refresh security tokens ourselves for a couple of different
reasons:
-- We definitely are going to have use cases where our container page is served
from a different domain than Shindig which means the OSAPI XHR to fetch
metadata/security tokens from Shindig would end up being cross domain and would
fail with a security exception. The standard workaround seems to be to proxy
the request with code running on your container domain back to your Shindig
server, however we'd like to avoid that.
-- It seems like in order for Shindig to generate a security token it needs to
authenticated the user making the request for tokens (so Shindig securely knows
who the user is), but we don't want to have to require authentication on our
Shindig servers. This is especially true if we have to proxy the request from
our container domain to our Shindig server -- in that case if Shindig required
authentication then we'd also have to also be proxying the users single sign on
tokens which is something we definitely don't want to do.
I suppose another approach would be for us to generate an encrypted security
token on the server side which we set in the container page using
shindig.auth.updateSecurityToken (similar to what the sample common container
does) so then instead of requiring authentication on Shindig it could just use
the security token present in the OSAPI call, but generating encrypted security
tokens in Rave just to be able to fetch generated encrypted security tokens
from Shindig doesn't seem right to me... And it also doesn't get around our
issue with the container/shindig hosts running on different domains (we'd still
need to proxy OSAPI XHR the calls).
Hopefully that makes sense.
Thanks!
--Jesse
> Allow for custom security token fetch function to be used when refreshing
> security tokens
> -----------------------------------------------------------------------------------------
>
> Key: SHINDIG-1580
> URL: https://issues.apache.org/jira/browse/SHINDIG-1580
> Project: Shindig
> Issue Type: Improvement
> Reporter: Jesse Ciancetta
> Attachments: gadget-token.patch
>
>
> Currently the common container is hard coded to make a gadgets.token OSAPI
> call back to Shindig when refreshing security tokens.
> I'm attaching a patch which allows users of the common container to override
> that default behavior by providing a custom function to use instead. I've
> followed the same pattern which is already in place for the GET_PREFERENCES
> override for providing a custom function for fetching gadget preferences.
> If this looks good to everyone I would be happy to go ahead and submit a
> patch against the container specification for this change as well.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
