vanilla-sshkeys-debug : Code : Canonical SSO provider

Get this branch:: bzr branch lp:~maxiberta/canonical-identity-provider/vanilla-sshkeys-debug

Only Maximiliano Bertacchini can upload to this branch. If you are Maximiliano Bertacchini please log in for upload directions.

Branch merges

No branches dependent on this one.

Rejected for merging into lp:canonical-identity-provider/release

Ubuntu One hackers: Pending requested 2020-01-16

Related bugs

Link a bug report

Related blueprints

Branch information

Owner:: Maximiliano Bertacchini

Project:: Canonical SSO provider

Status:: Development

Recent revisions

1710. By Maximiliano Bertacchini on 2020-01-16

DEBUG: vanilla ssh key view.

1709. By Jonathan Hartley on 2020-01-10

Unconditionally error if "not account.can_reset_password"

Don't try to special-case "deactivated" accounts, since we cannot reach
this code with that account.status value.

Don't special case "suspended" accounts, since that is the only
status value which can reach this bit of code.

Instead, just unconditionally refuse to send the password reset
and return an error.

There was a test of special-case for "deactivated" accounts,
but to reach that code, the test monkey-patched to create an
impossible situation. Without that patching, the test now
demonstrates what actually happens (both before this change
and after it) - i.e. a deactivated account can send a password
reset email.

Add a comment about test assertions using mock_logging,
which actually do nothing.

Fix a few comment typos.

Merged from https://code.launchpad.net/~tartley/canonical-identity-provider/rm-deactivated-check/+merge/377387

1708. By Jonathan Hartley on 2020-01-10

Remove code that cannot be reached.

The containing 'if not account.can_reset_password',
16 lines up from the deletion,
does not check whether there are any validated email addresses.
Instead it just checks that account.status must be either
Suspended or Deleted.

Suspended accounts are handled by an early return,
9 lines up from the deletion.

Deleted accounts also delete their associated email addresses,
so can not be retrieved by the Account.get_by_email call
near the start of this method.

There was a test for this deleted code,
but it monkey patched a fake value to make this code reachable.
I tried replacing the test with one that didn't do monkey patching
(e.g. using a deleted account would be the only way)
but was unable to make the code reachable.

In practice, accounts with no validated email addresses pass
right by this code, and end up reading from account.preferredemail,
14 lines below the deletion,
which falls back to using a new email address.

Merged from https://code.launchpad.net/~tartley/canonical-identity-provider/rm-no-verified-address-para/+merge/377382

1707. By Jonathan Hartley on 2020-01-10

Test fail diagnostics for bad response status code.

If a response has an unexpected status code,
display the response content
and the expected/actual status codes.

Merged from https://code.launchpad.net/~tartley/canonical-identity-provider/status-code-diagnostics/+merge/377377

1706. By Jonathan Hartley on 2020-01-10

Restore users ability to send password reset email to new addresses.

A branch was merged before Christmas to fix a security hole in the
password reset process. In that branch, out of an abundance of
caution, we also prevented password reset emails from being sent
to 'new' email addresses.
https://code.launchpad.net/~tartley/canonical-identity-provider/password-reset/+merge/376991

On reflection, the latter part was more cautious than required.
This MP restores the ability for the password reset email logic
to fall back to using an account's 'new' email address if no
preferred or validated email addresses exist.

Merged from https://code.launchpad.net/~tartley/canonical-identity-provider/allow-new-emails/+merge/377333

1705. By Karl Williams on 2020-01-09

Convert all error and logged-in user pages to Vanilla templates

Merged from https://code.launchpad.net/~deadlight/canonical-identity-provider/merge-3-user/+merge/375403

1704. By Jonathan Hartley on 2019-12-20

Prevent password reset security problem.

It's possible for an attacker to request a password reset
using a variation on an existing user's email which differs
only in case. For ASCII, this makes no difference, but for
unicode, different case may constitute a distinct email
address.

In such a case, it's important we email the password reset
token to the user's email which we have stored and validated,
rather than the variant of it provided and controlled by
the attacker.

If a user has no validated email address, we should not
send the password reset token to an unvalidated (new)
email address, which may not be read or may be controlled
by someone else. In this case we refuse to allow
password reset. The user can recover from this by
validating the email address they provided, or by
contacting support as they are prompted to do.

Merged from https://code.launchpad.net/~tartley/canonical-identity-provider/password-reset/+merge/376991