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.
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.
