[jira] [Updated] (WOOKIE-392) Replace persistent "WidgetInstance" with transient "AuthToken" similar to Shindig

["Scott Wilson (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WOOKIE-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Wilson updated WOOKIE-392:
--------------------------------

    Fix Version/s: 2.0.0

> 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
>             Fix For: 2.0.0
>
>         Attachments: AuthToken.java, AuthTokenCrypter.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/%3c48F3D140-9C46-429B-AA55-6A2729FC3057@gmail.com%3e



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)