Merge lp:~rharding/launchpad/email_notice_959482 into lp:launchpad
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Richard Harding on 2012-04-17 | ||||
| Approved revision: | no longer in the source branch. | ||||
| Merged at revision: | 15110 | ||||
| Proposed branch: | lp:~rharding/launchpad/email_notice_959482 | ||||
| Merge into: | lp:launchpad | ||||
| Diff against target: |
664 lines (+203/-68) 21 files modified
lib/lp/registry/browser/person.py (+1/-1) lib/lp/registry/browser/tests/test_productseries_views.py (+1/-1) lib/lp/registry/browser/tests/test_sshkey.py (+23/-18) lib/lp/registry/doc/person.txt (+9/-2) lib/lp/registry/doc/sshkey.txt (+3/-0) lib/lp/registry/emailtemplates/person-details-change.txt (+3/-0) lib/lp/registry/interfaces/person.py (+11/-0) lib/lp/registry/model/person.py (+37/-2) lib/lp/registry/stories/person/xx-add-email.txt (+31/-13) lib/lp/registry/stories/person/xx-add-sshkey.txt (+14/-0) lib/lp/registry/stories/person/xx-validate-email.txt (+8/-4) lib/lp/registry/stories/webservice/xx-person.txt (+14/-6) lib/lp/registry/subscribers.py (+4/-1) lib/lp/registry/tests/test_personnotification.py (+2/-0) lib/lp/services/authserver/tests/test_authserver.py (+10/-6) lib/lp/services/identity/model/emailaddress.py (+1/-0) lib/lp/services/mail/doc/sending-mail.txt (+7/-4) lib/lp/services/verification/browser/tests/logintoken-corner-cases.txt (+2/-0) lib/lp/services/verification/browser/tests/test_logintoken.py (+9/-5) lib/lp/services/verification/doc/logintoken.txt (+9/-4) lib/lp/services/verification/model/logintoken.py (+4/-1) |
||||
| To merge this branch: | bzr merge lp:~rharding/launchpad/email_notice_959482 | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Robert Collins (community) | Approve on 2012-04-17 | ||
| Graham Binns (community) | code | 2012-03-29 | Approve on 2012-04-03 |
|
Review via email:
|
|||
Commit Message
Add a notification email to a user whenever significant changes to their account are taking place.
Description of the Change
= Update =
This branch has been changed dramatically from the original submission. We've ditched the event and gone straight to sending emails via simple_sendmail. Resubmitting for code review since it's so different.
= Summary =
Launchpad should make more noise when important user information is changed in case it came from a malicious user. The frequency should be low enough that the extra warnings are worth the extra email notifications sent to users.
== Proposed Fix ==
Whenever a user adds an email address, changes their preferred email address, or adds/removes ssh keys, Launchpad should send a notification to the person that the information was changed with a note on how to proceed if those changes were not intentional.
== Implementation Details ==
A new method has been added to the Person interface/model, `security_
== Tests ==
*Note* We had to adjust many tests that validate and work with emails and ssh
keys since any time that they wanted to check that a confirmation email or
such was sent we also had to deal with the security notification getting sent
out as well.
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
== Demo and Q/A ==
Changing any of the listed properties should schedule an email with the correct note about the change.
== LoC ==
This is a security issue I've worked with Robert on to get into place with the
smallest LoC hit possible. There's no way to add this without adding LoC and
delaying release until I can find other places to reduce code would
inadvisable. Robert is requested as a reviewer to provide an exemption at this
time for this branch.
| Robert Collins (lifeless) wrote : | # |
This is an interesting branch.
I note that no discussion took place about the 400 odd additional LoC. Thats a shame - we really need to enforce that.
Here are some initial thoughts:
296 + >>> found = False
297 + >>> for from_addr, to_addrs, raw_msg in stub.test_emails:
298 + ... if 'token' in raw_msg:
299 + ... found = True
300 + ... token_url = get_token_
301 + ... token_url
302 + ... to_addrs
This is duplicated in the diff. I hear that functions can allow code reuse.
PersonAlteratio
The call site spends most of its time reconstructing what changed. I think the branch will shrink substantially if you just call the notifier when an appropriate change has happened.
tl;dr - I think you can halve the length of this branch without affecting clarity, test coverage or reusability.
| Robert Collins (lifeless) wrote : | # |
More notes while going through this in detail:
- teams - how are they handled? the code is user specific but nothing in person.py prevents a team having ssh/gpg keys. Probably a separate issue, but it would be good not to add new OOPSes :).
- oauth keys (adding only)
- gpg keys (adding only)
We can notify on removals but additions are the things that matter from a security perspective.
- LoginToken.new isn't quite the right place to trap outbound email validations; logintokens are used for a wide range of things including remote bugtracker logins, team merges and so forth. This is a bit unfortunate, because we have to choose between maximum safety (always notify) and user friendliness (don't double notify someone when they try to merge a team / claim an account). I've moved it to the code path relevant for additional-
I've pushed a non-event based branch to lp:~lifeless/launchpad/email_notice_959482 which you're welcome to pull from if you want to. It is missing 4 small and obvious tweaks to *existing* tests to note that an additional mail is sent as well (rather than the complex action-at-a-distant tests involving subscribers that you had). The resulting branch should be about +200 -60 lines. Still an increase, but much more pithy, and I think you'll agree that the email content people receive will be more useful.
| Robert Collins (lifeless) wrote : | # |
This looks pretty good and nice and compact :). it might be an idea - to check coverage - to stub out security_

Hi Rick,
The code looks good. I have some comments about tests but they're all of a documentation / comments nature. r=me with the changes below.
[0]
General comment on review docstrings: Your docstrings are all of the form:
"""We want the frobber to go boing when pressed."""
Test docstrings should be a statement of expected behaviour. So,
docstrings need to read as follows:
"""The frobber goes boing when pressed."""
I know this seems like mindless pedantry, but it saves time when
scanning through tests, and I'm a firm believer in being both a) a
strong TDD advocate and b) lazy.
[1]
366 + def test_change_ preferredemail( self):
367 + # The project_reviewed property is not reset, if the new licenses
368 + # are identical to the current licenses.
I'm guessing this is a C-P error :).
[2]
375 + # Assert form within the context manager to get access to the
376 + # email values.
s/form/from.
This occurrs a couple of times in the diff. I think you can actually get rid of the comments, since asserts- within- context- managers are a pretty common pattern now.
[3]
426 + We want to send the notification when the new email address is
427 + requested. This doesn't actually create an email address yet. It
428 + builds a LoginToken that the user must ack before the email address is
429 + added. The issue is security in alerting the owner of the account that
430 + a new address is being requested, so we need to notify at the time of
431 + request and not wait for the user to ack the new email address.
432 + """
This bit of documentation is useful. So it should be either next to the
code in question or in a doctest. Putting it in the docstring of the
unit test looks sensible, but you have to know which test to look for to
be able to find it.