Tien, it might be worth briefly the different use cases you are thinking of... It would definitely help the discussion
Best Jean-Noël On 30/03/11 00:28, Scott Wilson wrote: > 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.
