[
https://issues.apache.org/jira/browse/WOOKIE-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Wilson updated WOOKIE-392:
--------------------------------
Attachment: AuthTokenUtilsTest.java
AuthTokenUtils.java
AuthTokenCrypter.java
AuthToken.java
> 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
