Merge lp:~michael.nelson/launchpad/db-598464-get-or-create-from-identity into lp:launchpad/db-devel
| Status: | Merged |
|---|---|
| Approved by: | Michael Nelson on 2010-07-02 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 9526 |
| Proposed branch: | lp:~michael.nelson/launchpad/db-598464-get-or-create-from-identity |
| Merge into: | lp:launchpad/db-devel |
| Prerequisite: | lp:~stevenk/launchpad/db-software-center-agent-celebrity |
| Diff against target: |
596 lines (+257/-78) 9 files modified
lib/canonical/launchpad/database/account.py (+4/-2) lib/canonical/launchpad/interfaces/account.py (+14/-1) lib/canonical/launchpad/security.py (+20/-0) lib/canonical/launchpad/webapp/login.py (+20/-63) lib/canonical/launchpad/webapp/tests/test_login.py (+13/-9) lib/lp/registry/interfaces/person.py (+34/-0) lib/lp/registry/model/person.py (+55/-0) lib/lp/registry/tests/test_personset.py (+92/-1) lib/lp/testopenid/browser/server.py (+5/-2) |
| To merge this branch: | bzr merge lp:~michael.nelson/launchpad/db-598464-get-or-create-from-identity |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Abel Deuring (community) | code | 2010-06-30 | Approve on 2010-07-02 |
| Guilherme Salgado | 2010-07-01 | Pending | |
|
Review via email:
|
|||
Description of the Change
Overview
=======
This branch is part of the fix for bug 598464 - enabling the software center agent to get-or-create an LP person based on an openid identifier.
After a pre- (or mid-)implementation call with Francis, I've reworked the branch to re-use the existing code from webapp.
Details
======
I pulled out the relevant code from processPositive
Based on the comment in the code:
{{{
# The two lines below are duplicated a few more lines down,
# but to avoid this duplication we'd have to refactor most of
# our tests to provide an SREG response, which would be rather
# painful.
}}}
I updated the login_test tests to always provide the SREG response, as initially I was always calling self._getEmailA
Issues
=====
Always calling _getEmailAddres
For this reason, I had to make the changes in r9514 which I'm not particularly happy with, and I'd like to better understand why we need to do this (hence the request Guilherme :) ).
To test:
bin/test -vvm test_personset -m test_login
| Guilherme Salgado (salgado) wrote : | # |
| Michael Nelson (michael.nelson) wrote : | # |
{{{
13:55 < noodles775> Hi salgado, if you've got a spare few mins, can you take a look at the issue I've identified at: https:/
.nelson/
13:55 < noodles775> Let me know if I'm not making sense on the MP.
13:56 < salgado> noodles775, sure, I have it in my inbox and will get to it shortly
13:56 < noodles775> salgado: thanks.
14:06 < salgado> noodles775, in which case is the sreg extension not included in the response?
14:07 < noodles775> salgado: normal login with existing account. ie. 1) start dev server, 2) click login 3) enter <email address hidden>:test 4) click login. In
this case calling _getEmailAddres
14:08 < noodles775> It's not seen in the current code as _getEmailAddres
14:09 -!- abentley [~<email address hidden>] has quit [Ping timeout: 260 seconds]
14:10 < salgado> noodles775, that's weird because the code that generates the positive openid response is including the sreg extension unconditionally
14:10 * salgado tries to dupe
14:11 < salgado> indeed, duped
14:11 -!- abentley [~<email address hidden>] has joined #launchpad-reviews
14:12 < noodles775> Yeah, I'd assumed the sreg response should always be there, and was surprised too.
14:14 < salgado> noodles775, but this is a bug in the testopenid implementation
14:14 < noodles775> Where should I look?
14:14 < salgado> testopenid == the OpenID provider we use when developing/testing
14:14 < salgado> I'm checking it now
14:14 < salgado> noodles775, lib/lp/
14:15 < noodles775> OK, so we can be confident that the staging/production SSO always include the sreg.
14:15 < noodles775> Thanks.
14:15 < salgado> createPositiveR
14:15 -!- jtv-afk [~jtv@canonical
14:16 < salgado> noodles775, I think I've found the problem
14:17 < salgado> noodles775, OpenIDLogin.
14:17 < salgado> bug testopenid ignores that and only includes the nickname
14:17 -!- rinze is now known as jelmer-lunch
14:17 < salgado> s/bug/but
14:18 < noodles775> Right... I see.
14:18 < noodles775> So should it instead include *only* the requested items (email/fullname) or in addition to the nickname?
14:19 -!- abentley [~<email address hidden>] has quit [Quit: Ex-Chat]
14:19 < salgado> I think it's fine to include the 3 of them, but the nickname shouldn't be used anywhere
14:20 < noodles775> OK, I'll update it... thanks salgado !
14:22 < noodles775> salgado: also, I assume you don't have time to review the actual branch, but if you could have a brief look and make sure you think it's a sane change, that would be great.
14:24 < salgado> noodles775, sure, I can do that
14:25 < noodles775> Ta.
14:27 < salgado> noodles775, out of curiosity, why somebody needs a launchpad account to buy stuff from the software center? wouldn't a Ubuntu SSO account be more app...
| Abel Deuring (adeuring) wrote : | # |
(12:04:05) adeuring: noodles775: overall, your code looks good. Just one question: SHouldn't the "with MasterDBPolicy():" be moved from processPositive
(12:06:19) noodles775: adeuring: yes, you're right.
And a minor nitpick:
> @@ -1754,6 +1761,33 @@
> on the displayname or other arguments.
> """
>
> + def getOrCreateByOp
> + full_name, creation_rationale, comment):
> + """Get or create a person for a given OpenID identifier.
> +
> + This is used when users login. We get the account with the given
> + OpenID identifier (creating one if it doesn't already exist) and
> + act according to the account's state:
> + - If the account is suspended, we stop and raise an error.
> + - If the account is deactivated, we reactivate it and proceed;
> + - If the account is active, we just proceed.
> +
> + If there is no existing Launchpad person for the account, we
> + create it.
> +
> + :param openid_identifier: representing the authenticated user.
> + :param email_address: the email address of the user.
> + :param full_name: the full name of the user.
> + :param creataion_
> + be created, this indicates why it was created.
s/creataion_

Your general approach looks sane to me. I might be able to do a proper review today or tomorrow if you'd like.