…ict in deployment environment
…:klrmn] Klearman and Zach [:zcarter] Carter)
4c10bb2 Merge pull request #42 from zacc/add_is_this_your_computer a490f28 Add methods and test for 'is this your computer' git-subtree-dir: automation-tests/browserid git-subtree-split: 4c10bb2b2c46b6b56d224f52945b55c4e1c256f1
…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).