ATS-PFM-SEC-006 Use and recover a console sign-in: Capability Test Specification
Markdown Design / Platform / Security, Customers and Workspaces / Console Entry and Sessions / Capability Test Specification Coverage Rule gap: FND-PFM-SEC-063 Transition covered Validation covered Permission covered Edge gap: FND-PFM-SEC-063 Failure covered Boundary covered Concurrency gap: FND-PFM-SEC-063 Invariant covered Interaction covered Test Scenarios 13 scenarios proving CAP-PFM-SEC-006
01 Check neutral password failures failure browser negative test
Proves BR-CAP-PFM-SEC-006-01Preconditions Prepare known and unknown e-mail addresses. Steps Attempt password sign-in for both with invalid credentials. Expected Both display the same refusal message. Data Use the records described in the setup. Bound to Source react-console:e2e/dev/sign-in.dev.spec.ts #refuses a wrong password with one message that does not say whether the account exists 02 Check protected navigation and safe return paths boundary browser negative test
Proves BR-CAP-PFM-SEC-006-02Preconditions Start without a browser session. Steps Open a protected deep link, call a session-protected data route and submit an external return destination. Expected Sign-in can return to the safe deep link, the data route refuses access and the external destination falls back to home. Data Use the records described in the setup. Bound to Source react-console:e2e/dev/session.dev.spec.ts #sends a signed-out visitor to the login screen and back to the page they wanted 03 Check session restoration without persistent access tokens invariant unit test
Proves BR-CAP-PFM-SEC-006-03Preconditions Establish a signed-in browser session. Steps Inspect browser storage and reload a protected page. Expected No access token appears in persistent storage or readable cookies; the cookie-backed session restores on reload. Data Use the records described in the setup. Bound to Source react-console:lib/auth/__tests__/session.test.ts #keeps the access token in memory and the refresh token nowhere 04 Check permanent and temporary refresh failures failure unit negative test
Proves BR-CAP-PFM-SEC-006-04Preconditions Prepare a valid session. Steps Simulate refused renewal, a response without tokens and temporary provider unavailability. Expected The first two end the session with an explanation; temporary failure keeps access while the current token remains valid. Data Use the records described in the setup. Bound to Source react-console:lib/auth/__tests__/session.test.ts #ends the session when the route refuses, and tells whoever is listening why 05 Check protected navigation after sign-out transition browser test
Proves BR-CAP-PFM-SEC-006-05Preconditions Prepare a signed-in browser. Steps Sign out and navigate backward. Expected Session cookies are cleared and the protected page cannot be reopened through history or its address. Data Use the records described in the setup. Bound to Source react-console:e2e/dev/session.dev.spec.ts #leaves nothing of the console behind, by URL or by the back button 06 Check callback state, token verification and refusal wording validation browser negative test
Proves BR-CAP-PFM-SEC-006-06Preconditions Prepare the social callback screen. Steps Send an unsolicited code, wrong state, forged tokens, cancellation and provider refusal. Expected The first three fail verification; cancellation and provider refusal receive their distinct explanations. Data Use the records described in the setup. Bound to Source react-console:e2e/controlled/social-callback.controlled.spec.ts #refuses a code that arrived in a browser which never started a sign-in 07 Check recovery-code and password constraints validation browser negative test
Proves BR-CAP-PFM-SEC-006-08Preconditions Prepare an account eligible for password recovery. Steps Request known and unknown addresses, try wrong and valid codes, reuse the valid code and try a weak password. Expected Request confirmations match; the wrong and reused codes fail, the valid code works once and weak-password refusal explains the policy. Data Use the records described in the setup. Bound to Source react-console:e2e/dev/password-recovery.dev.spec.ts #confirms a request the same way whether or not the address has an account 08 Check ownership and type restrictions on password change permission api negative test
Proves BR-CAP-PFM-SEC-006-09Preconditions Prepare password and Google-only accounts. Steps Change a password with its owner’s token, another person’s token, insufficient scope and a Google-only account. Expected The owner’s valid request succeeds and is audited; another identity returns 403, insufficient scope returns 400 and a social-only account returns 409. Data Use the records described in the setup. Bound to Source services-platform:modules/security/tests/e2e/users.e2e.spec.js #changes the caller's own password with the caller's own token, and audits it 09 Check administrative recovery permissions and reach permission api negative test
Proves BR-CAP-PFM-SEC-006-10Preconditions Prepare administrators with and without password-management authority. Steps Start recovery for a reachable member and a member of another customer. Expected Only the authorized, in-reach request starts recovery; the remaining requests fail. Data Use the records described in the setup. Bound to Source services-platform:modules/security/tests/e2e/users.e2e.spec.js #starts a recovery for the caller's own account (a code sent) and for a user in scope (recovery at next sign-in) 10 Check fresh membership reads after lifecycle changes transition api negative test
Proves BR-CAP-PFM-SEC-006-11Preconditions Prepare an active membership. Steps Suspend and resolve the current user, reinstate and resolve again, then revoke and resolve again. Expected Fresh lookups refuse suspension, accept reinstatement and refuse revocation with the relevant explanation; cached gateway propagation is outside these bindings. Data Use the records described in the setup. Bound to Source services-platform:modules/security/tests/integration/services/invitations/resolve-current-user.integration.spec.js #refuses a suspended caller on the request after the suspension, not at the next token 11 Use and recover a console sign-in with join through an invitation interaction api proposed
Proves BR-CAP-PFM-SEC-005-04BR-CAP-PFM-SEC-006-02Preconditions An invited person has no console session. Steps Accept the invitation with a valid password and sign in to the protected destination. Expected The active account reaches the destination through a new session without another acceptance write. Data An isolated customer with two workspaces, ordinary and staff identities, and records owned by this run. Source services-platform:modules/security/tests/unit/services/invitations/accept-invitation.spec.js #sets the chosen password in Cognito, then accepts, activates and makes the pending roles real in one transaction,react-console:e2e/dev/session.dev.spec.ts#sends a signed-out visitor to the login screen and back to the page they wanted 12 Use and recover a console sign-in with understand available workspace access interaction api proposed
Proves BR-CAP-PFM-SEC-006-03BR-CAP-PFM-SEC-007-08Preconditions A signed-in person has an in-force workspace assignment. Steps Reload the browser, wait for context, and then repeat with a person whose assignments are ineffective. Expected Restoration admits protected content only after context succeeds; the second person receives No Access. Data An isolated customer with two workspaces, ordinary and staff identities, and records owned by this run. Source react-console:lib/auth/__tests__/session.test.ts #keeps the access token in memory and the refresh token nowhere,react-console:e2e/controlled/security-context.controlled.spec.ts#will not open the console when the Platform cannot say what somebody may do, and opens it on the retry 13 Use and recover a console sign-in with maintain console memberships interaction api negative proposed
Proves BR-CAP-PFM-SEC-006-10BR-CAP-PFM-SEC-009-03Preconditions A console member has a valid session and an administrator can suspend that member. Steps Suspend the member and read current membership using a fresh request. Expected The request refuses active use without treating a retained browser token as active membership. Data An isolated customer with two workspaces, ordinary and staff identities, and records owned by this run. Source services-platform:modules/security/tests/e2e/users.e2e.spec.js #requires the manage-passwords permission (Knox enforces it at the gateway) and refuses a user of another customer,services-platform:modules/security/tests/integration/services/membership/console-users.integration.spec.js#leaves the e-mail address, the status and the wall exactly as they were ← Previous Capability Test Specification ATS-PFM-SEC-005 · Join through an invitation: Capability Test Specification Next Capability Test Specification → ATS-PFM-SEC-007 · Understand available workspace access: Capability Test Specification