Log completed password resets as $profile_reset

app.js

@@ -369,7 +369,7 @@ function buildApp(castle = require('./castle')) {
     // A new password that differs from the current one is a successful reset.
     const castleStatus =
       password === process.env.valid_password ? '$failed' : '$succeeded';
-    const castleType = '$password_reset';
+    const castleType = '$profile_reset';
 
     const payloadToCastle = {
       type: castleType,
@@ -383,7 +383,7 @@ function buildApp(castle = require('./castle')) {
       context: buildContext(req),
     };
 
-    // $password_reset is a good fit for the non-blocking log endpoint: record
+    // $profile_reset is a good fit for the non-blocking log endpoint: record
     // the event without waiting on a verdict.
     let error;
     try {

demo_config.js

@@ -13,7 +13,7 @@ const demos = {
   },
   password_reset: {
     friendly_name: 'password reset',
-    blurb: 'Record a password-reset event with the non-blocking log endpoint.',
+    blurb: 'Record a password-reset event ($profile_reset) with the non-blocking log endpoint.',
   },
   lists: {
     friendly_name: 'lists',

readme.md

@@ -13,7 +13,7 @@ Server-rendered pages:
 
 - **sign up** – `$registration` to `filter` (anonymous, so the email goes in `params`): `$attempted` for a new email, `$failed` (resolved via `matching_user_id`) for an email that already exists
 - **login** – `$login` reusing one request token across two calls: `filter` `$attempted` first, then `risk` `$succeeded` on success or `filter` `$failed` (wrong password / unknown user); the verdict (allow / challenge / deny), risk score and signals are surfaced per step
-- **password reset** – `$password_reset` via the non-blocking `log` endpoint
+- **password reset** – `$profile_reset` via the non-blocking `log` endpoint
 - **lists** – the Lists API (`createList`, `fetchAllLists`)
 - **privacy** – the Privacy API (`requestUserData`, `deleteUserData`)
 - **webhooks** – incoming Castle webhooks are signature-verified with `verifyWebhookSignature` (against the `X-Castle-Signature` header) and the most recent payloads are listed

test/sdk-integration.test.js

@@ -291,7 +291,7 @@ describe('failover', () => {
 });
 
 describe('log (fire-and-forget)', () => {
-  test('password reset POSTs $password_reset to /v1/log', async () => {
+  test('password reset POSTs $profile_reset to /v1/log', async () => {
     const fetch = recordingFetch({ 'POST /v1/log': () => httpResponse(200, {}) });
 
     const res = await request(buildApp(makeCastle(fetch)))
@@ -305,7 +305,7 @@ describe('log (fire-and-forget)', () => {
     expect(fetch.calls).toHaveLength(1);
     expect(fetch.calls[0].method).toBe('POST');
     expect(fetch.calls[0].pathname).toBe('/v1/log');
-    expect(fetch.calls[0].body).toMatchObject({ type: '$password_reset' });
+    expect(fetch.calls[0].body).toMatchObject({ type: '$profile_reset' });
   });
 
   test('logout POSTs $logout to /v1/log', async () => {

views/password_reset.pug

@@ -17,9 +17,9 @@ block desc
   p Assume the user already passed your reset challenge (e.g. an emailed OTP). Enter a value 
     em different from
     |  the valid password to send 
-    code $password_reset / $succeeded
+    code $profile_reset / $succeeded
     | , or the valid password to send 
-    code $password_reset / $failed
+    code $profile_reset / $failed
     | . (The password is not actually changed.)
 
 block scripts