On Fri, Nov 12, 2010 at 2:30 PM, Michael Vogt <email address hidden> wrote:
> The LPAuthorizer in the current form can indeed go. We have two cases
> where we need authorization:
Thanks for the info Michael!
>
> 1. Moderation (moderator verification)
> For this we use a webapp anyway and can leverage OpenID with launchpad to get the data synced. AFAIK ubuntu-sso does not have a "group" notion so for moderators we will require a launchpad account. I think that is acceptable.
I think I'm confused as to why we need to even use Launchpad groups
(or involve launchpad at all). We could simply add people to a local
django 'moderators' group on the server.
(which seems to be what the current code is doing - although as you
mentioned, I might have missed the fact that it was expecting a
Launchpad group to be synced locally).
>
> 2. Submit new review (user/reviewer verification)
> For this we only require a ubuntu SSO account. Most users will either have the account token stored via ubuntu-sso already or need to create a new account at this point. At this point we need to present "rnr-server" something that it can use to verify that I'm really "Michael Vogt". The current implementation is doing that by forcing the client to send the token over to the rnr-server. With that token the rnr-server makes a API call to launchpad (or ubuntu-sso later) to get name/display_name. This way we ensure that there are no fake reviews. Sending over the token is obviously pretty bad. A possible alternative is to create a request on the client side that is then send to the rnr-server. Together with the oauth sha1/nonce/timestamp feature this should actually be secure as the request can not be re-used (because of the nounce). And all that can be done with it is to ask "what is my name". But IIRC/AFAIK nonce/timestamp is not support (yet) by our infrastructure.
>
Yes, given that the client has already authenticated with SSO, the
single-signon service should allow you to do a normal authenticated
API request to the rnr-server that the rnr-server verifies with sso
(ie. without the client having to do anything special). I think that's
what Anthony added to the SCA for bug 609025 (which seems to be
solving the same issue for the SCA?)
Also, another option that might be worth considering: move the UI for
writing a review to the browser? So clicking the review link on the
client would open a browser, and if it's the first time, they see "You
are authenticating with Ubuntu Ratings and Reviews as Michael Vogt"
etc., as per normal. Or what are the benefits of doing the review UI
in the client (integrated experience I guess?)
I'd be keener for the former, but if that's not possible...
On Fri, Nov 12, 2010 at 2:30 PM, Michael Vogt <email address hidden> wrote:
> The LPAuthorizer in the current form can indeed go. We have two cases
> where we need authorization:
Thanks for the info Michael!
>
> 1. Moderation (moderator verification)
> For this we use a webapp anyway and can leverage OpenID with launchpad to get the data synced. AFAIK ubuntu-sso does not have a "group" notion so for moderators we will require a launchpad account. I think that is acceptable.
I think I'm confused as to why we need to even use Launchpad groups
(or involve launchpad at all). We could simply add people to a local
django 'moderators' group on the server.
http:// docs.djangoproj ect.com/ en/1.2/ topics/ auth/#groups
(which seems to be what the current code is doing - although as you
mentioned, I might have missed the fact that it was expecting a
Launchpad group to be synced locally).
> timestamp feature this should actually be secure as the request can not be re-used (because of the nounce). And all that can be done with it is to ask "what is my name". But IIRC/AFAIK nonce/timestamp is not support (yet) by our infrastructure.
> 2. Submit new review (user/reviewer verification)
> For this we only require a ubuntu SSO account. Most users will either have the account token stored via ubuntu-sso already or need to create a new account at this point. At this point we need to present "rnr-server" something that it can use to verify that I'm really "Michael Vogt". The current implementation is doing that by forcing the client to send the token over to the rnr-server. With that token the rnr-server makes a API call to launchpad (or ubuntu-sso later) to get name/display_name. This way we ensure that there are no fake reviews. Sending over the token is obviously pretty bad. A possible alternative is to create a request on the client side that is then send to the rnr-server. Together with the oauth sha1/nonce/
>
Yes, given that the client has already authenticated with SSO, the
single-signon service should allow you to do a normal authenticated
API request to the rnr-server that the rnr-server verifies with sso
(ie. without the client having to do anything special). I think that's
what Anthony added to the SCA for bug 609025 (which seems to be
solving the same issue for the SCA?)
Also, another option that might be worth considering: move the UI for
writing a review to the browser? So clicking the review link on the
client would open a browser, and if it's the first time, they see "You
are authenticating with Ubuntu Ratings and Reviews as Michael Vogt"
etc., as per normal. Or what are the benefits of doing the review UI
in the client (integrated experience I guess?)
I'd be keener for the former, but if that's not possible...