Thanks Scott, Jean-Noël,
There are several usecases of using widget (that access to oAuth
protected resource) but I think they are all based on 2 element cases of
widget instance key:
+ Case1: widget instance key is not visible to public (user must login
to widget container before working with widget)
+ Case2: widget instance key is (possibly) visible to public (e.g.: user
wants to publish widget instance for the purpose of easily access from a
limited resource device such as mobile phone or when the widget instance
key is revealed because of sniffing)
For Case1: I share the same opinion with Scott, access token could be
stored in Widget Instance object, but it is should not be accessible
with REST API (create a new table in wookie db server for dealing with
oAuth parameters or storing in existing one with the same purpose)
For Case2: I have not yet figure out another way other than limit the
use of oauth access token in each session. That cause the irritation
Scott has mentioned (user must introduce his credential each time a new
working session established). Please show me if you have any idea of
safely store the access token ?
Tien.
On 31/03/11 08:55, Jean-Noel Colin wrote:
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.
