diff --git a/lib/browserid/fake_verification.js b/lib/browserid/fake_verification.js index 8c7194d2b87af824b2355ceb45248e52c9844ae7..6aa1618872d7b85a90b43da368c3fe6977df4667 100644 --- a/lib/browserid/fake_verification.js +++ b/lib/browserid/fake_verification.js @@ -59,7 +59,6 @@ if (!/^test_/.test(c)) { exports.addVerificationWSAPI = function(app) { app.get('/wsapi/fake_verification', function(req, res) { var email = url.parse(req.url, true).query['email']; - console.log(email); db.verificationSecretForEmail(email, function(secret) { if (secret) res.write(secret); else res.writeHead(400, {"Content-Type": "text/plain"}); diff --git a/lib/load_gen/signup.js b/lib/load_gen/signup.js index 12af0e90b1463be074fb6473b9577865bf951508..fc6548d7776d748f424d46365c5c1c78a754c740 100644 --- a/lib/load_gen/signup.js +++ b/lib/load_gen/signup.js @@ -46,30 +46,22 @@ exports.startFunc = function(cfg, cb) { // A new user signing up for browserid looks like this in terms of // network transactions: // - // 1. RP includes include.js + // 1. RP includes include.js // 2. users' browser loads all code associated with dialog - // 3. in page javascript calls CSRF to get a CSRF token + // 3. in page javascript calls /wsapi/session_context to get a CSRF token // 4. /wsapi/have_email is called some number of times to give feedback as the // user types in their email address // 5. /wsapi/stage_user is called to stage the user for creation when the // user clicks "continue" after having chosen a password - // 6. /wsapi/registration_status is called once for each second it takes the + // 6. /wsapi/user_creation_status is called once for each second it takes the // user to go to their email and click on the verification link // 6.5. in the load testing environment, we make a call to the server to get // the email verification token - // 7. /prove is called on the server, passing in the authentication token - // 8. /manage is called on the server as the user's page transitions from - // the verify screen to the manage screen. - // 9. /wsapi/sync_emails is called from the client (XXX: this is probably a bug, - // there's no utility to this) - // 10. /wsapi/set_key is called from the client to inform the server of the - // user's public key (XXX: this will go away when we migrate to certificates - // and instead, the server will be asked to sign the user's public key.) - // 11. the RP will call /verify to verify a generated assertion - - // XXX: for now this is *api only*, that is we omit steps above that would just be - // the serving of static pages. it is unknown to me whether static page simulation - // is useful. + // 7. /wsapi/email_for_token is called (by the landing page) + // 8. /wsapi/session_context is called again (by the landing page) + // 9. /wsapi/complete_user_creation is called (by the landing page) + // 10. /wsapi/cert_key is called by the dialog + // 11. /verify is invoked // get a user var user = userdb.getNewUser();