From 810b1019fcb87232fa759d5ffd3380f6471d29b5 Mon Sep 17 00:00:00 2001
From: Lloyd Hilaiel <lloyd@hilaiel.com>
Date: Tue, 15 Nov 2011 18:19:35 -0700
Subject: [PATCH] update documentation of what happens during user signup in
loadgen tool #504
---
lib/browserid/fake_verification.js | 1 -
lib/load_gen/signup.js | 24 ++++++++----------------
2 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/lib/browserid/fake_verification.js b/lib/browserid/fake_verification.js
index 8c7194d2b..6aa161887 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 12af0e90b..fc6548d77 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();
--
GitLab