On 29 Mar 2011, at 16:45, Hoang Minh Tien wrote: > > > On 29/03/11 16:58, Scott Wilson wrote: >> On 29 Mar 2011, at 15:11, Hoang Minh Tien wrote: >> >>> On 29/03/11 08:38, Scott Wilson wrote: >>>>> For the storage of "access token" I'd like to store it as temporary >>>>> session variable rather than permanently in wookie db. I don't know >>>>> whether is is possible because each time refreshing the page which >>>>> contains widget, my Tomcat generate a new session id for widget. How do >>>>> you think ? I have a mal-configured Tomcat server ? >>>> I haven't come across this myself, its possible there is an issue with >>>> your Tomcat configuration. >>>> >>>> Why is it important not to save access tokens between sessions? Is this a >>>> requirment of the oAuth profile? >>>> >>>> >>> Hi Scott, >>> In fact, oAuth doesn't require to store token in session variables but I've >>> not yet found out another solution for our project. I briefly resume as >>> following: >>> An iframe tag for widget W is embedded in web page P1, widget W requires >>> access to resource R (oAuth authz enabled). >>> User U1 is authorized to access R >>> User U2 is not authorized to access R >>> Both of users could access page P1 >>> >>> In this proposal: >>> U1 opens browser B1 to access P1 and performs oAuth authn and granting >>> operations through widget W, and after that, working on it. >>> If token is permanently stored as widget preference, there is a risk that >>> U2 could open P1 and access to R (which is not intentionally allowed) >>> So I think of storing access token in session variable, i.e, when U1 opens >>> browser B to access P1, there is a session established between wookie and >>> browser B1, so even U2 access the page P1, he has to provide a proper >>> credential data to allow W access R because the access token is not >>> remembered by W. >>> Please tell me if Wookie currently supports a mechanism for managing such >>> kind of session variables or there is another way to deal with that. >> Hmm, I'm not sure this is quite correct. >> >> If: >> >> U1 accesses the page context P1, within which there is Widget Instance WI1 >> of Widget W. >> U2 accesses the page context P1, within which there is Widget Instance WI2 >> of Widget W. > Yes, I agree that it works perfectly for the case each user has his own > Widget Instance. But I mean the case U2 also has the right to accesses WI1, > like U1 has a Widget which manipulates private stuff R (sharing among a small > group U1, U3, U4) in moodle, U1 also wants to have the same widget on his > blog so he copies and paste the embedded iframe code into his blog which is > open to everyone but only the person in his group (U3, U4) could work on R > when viewing U1's blog not U2 who is not authorized on R. > I would like to have a protection for a single widget instance which is > duplicated in multiple widget containers.
Ah OK, so if someone decides to publish their widget instance they don't also share any access that widget has so that someone else could get the widget to act on their behalf. I can see that use case. So the idea then is to only get an access key for each active session and then forget it between sessions? Would this necessitate users having to re-grant permission each time they view it? >> U1 grants WI1 access to R >> WI1 stores the access key >> >> In this case, U2 cannot access R unless they login as U1; P1 does not >> actually store anything. >> >> The WIdget Instance is to some extent the "session" object in Wookie. >> >> In general I'm not too happy about storing security information in Widget >> Preferences, but the Widget Instance object would seem the natural object to >> store such a token against. >> >>> Thank you Scott. >>> Tien. >>
