No subject


Sun Apr 26 06:47:01 MDT 2009


<div><br></div><div>c) (From (a, b)) The ICredentialsChecker needs to be ab=
le to communicate the expiration to the avatar.</div><div>d) The ICredentia=
lsChecker and IRealm can only communicate through the avatarId.</div><div>
<br></div><div>Conclusion (from c,d): The expiration time needs to be in th=
e avatarId?</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:bre=
ak-word">
<div><div><blockquote type=3D"cite"><div>=C2=A0=C2=A0 =C2=A0- the refresh t=
oken (another ascii string, similar to the access token, optional)</div></b=
lockquote><div><br></div></div><div>Implementation detail of the authentica=
tion protocol. =C2=A0The client library and server library should be transp=
arently refreshing this without telling either the client application code =
or server application code, right?</div>
</div></div></blockquote><div><br></div><div>Sure, but we&#39;re still writ=
ing library code here.</div><div><br></div><div>If the avatar interface=C2=
=A0isn&#39;t actually IResource, but a new interface IAccessToken, getting =
the refresh token later might be feasible. (It should be a different interf=
ace, because in order to create a refresh token outside of this entire cred=
 cycle, I need to know about the thing it&#39;s refreshing -- so, the infor=
mation in the response needs to be easily accessible and not just an opaque=
 IResource).</div>
<div><br></div><div>I agree entirely that clever client library code would =
abstract this mess away from application code. However, right now this code=
 still needs to somehow be able to eventually produce HTTP responses that d=
on&#39;t abstract anything yet and just contain all the appropriate data, b=
ecause that&#39;s just what the OAuth spec says it needs to be able to do. =
There isn&#39;t any real application code in the token endpoint; they&#39;r=
e pretty similar for all OAuth setups, and customization would typically ha=
ppen through implementing the appropriate ICredentialsChecker.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break=
-word"><div><div><blockquote type=3D"cite"><div>=C2=A0=C2=A0 =C2=A0- scope =
(an ascii string consisting of a set of space-separated words, optional)</d=
iv>
</blockquote></div></div><div><br></div>This part doesn&#39;t quite fit, bu=
t could be expressed in one of two ways: a modification to the avatar ID, o=
r as some extra structure on the Mind that modifies what functionality the =
Realm bundles in to your avatar implementation (without changing the interf=
ace provided by that object, of course).</div>


</blockquote><div><br></div><div>Unfortunately I don&#39;t believe this can=
 be done through the mind. Again working under the previous assumption that=
 ICredentialsChecker and not the IRealm is responsible for creating the acc=
ess token, and scope is known to the thing that makes the access token, the=
 ICredentialsChecker knows about the scope. Unfortunately the only way to p=
ass stuff =C2=A0between the ICredentialsChecker and the IRealm is the avata=
r ID, so you don&#39;t have a choice.</div>
<div><br></div><div>=C2=A0</div></div>thanks for your infinite patience,
<div>Laurens</div>

--0016364ef5036a18a2048feab383--



More information about the Twisted-Python mailing list