[
https://issues.apache.org/jira/browse/WOOKIE-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502949#comment-13502949
]
Scott Wilson commented on WOOKIE-392:
-------------------------------------
You're absolutely correct Tien. What I have there is a more or less exact copy
of the method Shindig uses for tokens but what I haven't yet added are the
isExpired and getUpdatedToken methods, and the token expiry time.
Once the maxTTL value is added to the token then it would have the effect of
making tokens expire (usually one hour). We would then need to add a means for
a widget to request an updated token within the same session.
See https://cwiki.apache.org/SHINDIG/security-tokens.html for more info on how
Shindig uses tokens. Although to be honest the code is easier to understand:
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/auth/SecurityToken.java
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/auth/AbstractSecurityToken.java
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/auth/BasicSecurityToken.java
Otherwise the implementation would behave as you might expect, with the
returned url having an "st=" parameter with the encrypted token value, and
should behave on the client/browser side in the same way they do at present
(including embedding in multiple containers)
The main consequence for the server side of Wookie would be that WidgetInstance
would no longer need to be persisted.
> 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
