[
https://issues.apache.org/jira/browse/WOOKIE-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502944#comment-13502944
]
Hoang Minh Tien commented on WOOKIE-392:
----------------------------------------
Hi Scott,
That sounds interesting but I'm not sure that I fully understand what you wrote
so sorry for my naive questions:
I just skim through AuthTokenUtilsTest, I see only the algol to encrypt and
decrypt a set of params for instantiating widget so if I'm not mistaken, there
is only one-one relation between this set of params and the auth token, isn't
it ? If it is I don't see much advantage if we change widget instance id key to
authtoken.
Could you explain more about the use of AuthToken in Wookie (or please show me
the spec of using AuthToken in Shindig) ?
If we go with the new implementation, can widget instance be embedded in a
simple web browser ? can a single widget instance still be embedded in multiple
containers ? Thanks a lot.
Tien.
> Replace persistent "WidgetInstance" with transient "AuthToken" similar to
> Shindig
> ---------------------------------------------------------------------------------
>
> Key: WOOKIE-392
> URL: https://issues.apache.org/jira/browse/WOOKIE-392
> Project: Wookie
> Issue Type: Improvement
> Reporter: Scott Wilson
> Attachments: AuthTokenCrypter.java, AuthToken.java,
> AuthTokenUtils.java, AuthTokenUtilsTest.java
>
>
> Hi everyone,
> Ate suggested a while back the idea of making core Wookie capabilities work
> in an "SPI" fashion,
> i.e. make it possible for the container to inject its own implementations of
> core services
> such as "Preferences" etc., so these can be integrated with the container
> backend rather than
> managed separately by Wookie.
> However, the way we handle Widget instantiation (widget user sessions, in
> effect) in Wookie
> by using persistent IWidgetInstance beans isn't really compatible with this
> approach, as it
> prevents decoupling things like Preferences, OAuth tokens, and Widget
> metadata into discrete
> services.
> One solution is to adopt the model used by Shindig and inject an encrypted
> token into the
> Widget and use that for subsequent requests. The token is then unwrapped by
> Wookie and used
> to verify the request, and obtain the parameters to be used in relevant calls
> (e.g. to get/set
> preferences, get the referenced Widget metadata etc).
> I've done some experiments with reusing the OpenSocial Token algorithm used
> in Shindig to
> see how this could work, and it looks like it would be OK. However, it would
> mean another
> big refactoring of the backend.
> PROs:
> - more consistent with Shindig and OpenSocial model
> - one less thing to manage as a persistent bean class
> - decouples Preferences, Widget metadata, Shared Data, Participants and oAuth
> Tokens, making
> them capable of being wrapped with SPIs
> CONs:
> - yet more refactoring
> - will not be backwards compatible
> If we do decide this is a good idea, it may be worth creating a branch for it
> as it would
> touch ~30 classes.
> See
> http://mail-archives.apache.org/mod_mbox/incubator-wookie-dev/201206.mbox/%[email protected]%3e
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
