Please sign in to comment.
Bug #2307: don't expire existing sessions when adding a secondary add…
…ress If a persona.org account is initially created with a "primary" address (meaning an address served by a participating IdP, so persona.org is given an assertion from that IdP as proof of ownership), the new account will not have a password associated with it. If you then add a "secondary" address (meaning an address *not* served by a participating IdP, requiring an email challenge to prove ownership), you will have to set up a password when you add the secondary. The establishment of this password should *not* invalidate any sessions that were set up earlier. In Bug #2307, this manifested as the first browser (in which the add-secondary-email operation was started, so it had the old session and was waiting for the operation to complete, polling /wsapi/email_addition_status all the while) receiving a "400 Unauthorized" error when the email challenge link was opened in a second browser (which thus got a new session). The test for this effect lives in tests/primary-then-secondary-test.js, which need the same 2-second delay as password-update-test.js (to make sure that the modified lastPasswordReset time was actually different than the previous value, so the session really would be expired).
- Loading branch information...
Showing with 41 additions and 2 deletions.