DEV Community: KillianBerg5391

Staged Profile State and Session Revocation over Immediate FastAPI Account Deletion

KillianBerg5391 — Wed, 26 Aug 2026 12:38:21 +0000

A healthtech account shutdown strategy has to separate profile state and session revocation from the later deletion of clinical, billing, or audit data. Treating those moments as one database operation makes a managed-auth migration look easy in a notebook and dangerous in production.

Short answer: choose staged account shutdown over immediate deletion: freeze profile changes, revoke every application session, block Google and GitHub sign-in, retain only the records required by policy, and let a separate, retryable process perform eventual deletion. Immediate purge is suitable only when no retention, recovery, or audit obligation can apply.

The evaluation constraint is simple: after shutdown begins, no old session or social login may restore access, while an authorized worker must still be able to explain what remains and why. That is the result to test. Deletion latency is secondary.

How should account shutdown coordinate profile state, session revocation, and eventual deletion?

Use one authoritative lifecycle state for the local account, then make authentication and deletion obey it. A practical model has active, shutdown_pending, retained, and deleted states. The exact labels don't matter; the invariants do.

In active, profile edits and new sessions are allowed. Moving to shutdown_pending records the decision, freezes mutable profile fields, increments a session epoch, and denies every new login. A retention decision then moves the account to retained with a deletion eligibility time, or directly queues deletion when policy permits. deleted is terminal for the local account, although independently governed records may remain under their own retention rules.

That separation prevents a subtle failure during migration off a managed provider. Google and GitHub identify an external principal, but the local account decides whether that principal may enter the application. If the callback handler creates or reactivates a profile merely because a provider returned a valid identity, shutdown can be undone by the next social sign-in. The callback must resolve the existing provider link, load the local lifecycle state, and refuse session issuance unless that state is active.

One gate. Everywhere.

Keep the lifecycle check below individual login handlers so password, Google, GitHub, refresh-token, and support-assisted flows cannot drift. During the migration, the old and new authentication paths should consult the same local decision point. This makes dual-running testable without allowing either provider stack to become the source of truth for account status.

The simple delete-first model fails the migration test

The tempting design is a DELETE handler that removes the profile row, clears the browser cookie, and schedules whatever cleanup remains. It passes a happy-path demo. It also combines four decisions that fail differently: whether access ends, whether sessions remain valid, whether data must be retained, and whether physical erasure has completed.

Consider the awkward sequence. A user has two browser sessions and one mobile session. They request shutdown from a browser while a refresh request is already in flight. Their Google identity and GitHub identity both map to the same local account. A delete-first implementation may clear one cookie yet leave two server-side credentials usable; if it removes the provider links first, a later callback can look like a new person and create a fresh account. If cleanup then retries without a stable account identifier, workers may no longer know which derived records belong to the deletion request. None of these are exotic provider behaviors. They are consequences of collapsing access control and erasure into one moment.

The staged design makes the first transaction small and decisive. It changes the lifecycle state, advances a monotonic session epoch, stores the shutdown request time and policy decision, and emits an outbox event in the same local transaction. Session validation compares the credential's epoch with the account's current epoch and also requires active; a mismatch ends access even if a cache or token has time left. The browser can receive a generic signed-out response, but clearing client state is cleanup, not the security boundary.

Don't depend on timing.

OWASP recommends invalidating sessions after reauthentication and other high-risk events, and it warns that session identifiers must be protected throughout their lifecycle. Account shutdown is at least as consequential as a credential change. Apply revocation centrally, require recent authentication before accepting the request, and avoid revealing through the response whether a particular social identity exists.

A focused FastAPI domain example

The useful code is the transition rule, not a vendor-specific callback. This Python example produces the atomic changes an application service should persist. Storage, queues, and token formats stay behind interfaces, which keeps the rule identical while the managed provider is being replaced.

from dataclasses import dataclass
from datetime import datetime, timedelta, timezone
from enum import StrEnum


class AccountState(StrEnum):
    ACTIVE = "active"
    SHUTDOWN_PENDING = "shutdown_pending"
    RETAINED = "retained"
    DELETED = "deleted"


@dataclass(frozen=True)
class Account:
    account_id: str
    state: AccountState
    session_epoch: int


@dataclass(frozen=True)
class ShutdownPlan:
    state: AccountState
    session_epoch: int
    requested_at: datetime
    delete_after: datetime
    event_name: str = "account.shutdown.requested"


def plan_shutdown(
    account: Account,
    requested_at: datetime,
    retention: timedelta,
) -> ShutdownPlan:
    if requested_at.tzinfo is None:
        raise ValueError("requested_at must be timezone-aware")
    if retention < timedelta(0):
        raise ValueError("retention cannot be negative")
    if account.state is not AccountState.ACTIVE:
        raise ValueError("account is not active")

    return ShutdownPlan(
        state=AccountState.SHUTDOWN_PENDING,
        session_epoch=account.session_epoch + 1,
        requested_at=requested_at.astimezone(timezone.utc),
        delete_after=requested_at.astimezone(timezone.utc) + retention,
    )


def can_issue_session(account: Account, credential_epoch: int) -> bool:
    return (
        account.state is AccountState.ACTIVE
        and credential_epoch == account.session_epoch
    )

The service layer should write the returned plan and its outbox record atomically. A worker can then process deletion idempotently: lock the account, verify that delete_after has passed, check for a legal hold or changed retention decision, erase eligible profile fields and provider links, and mark the account deleted. Repeating the worker must produce the same final state. For a healthtech system, the deletion inventory should distinguish authentication profile data from medical, claims, consent, and audit records; “delete the user” is too vague to be an executable policy.

Keep provider unlinking late enough that shutdown retries retain a stable mapping, but never treat an external unlink as session revocation inside the application. Those are different controls. A provider can stop authorizing future grants while an application session created earlier still exists, so the local epoch and lifecycle gate remain necessary.

What to measure before adopting the staged choice

Turn the migration into an eval harness. Feed the same fixtures through the legacy and replacement authentication paths, then assert lifecycle outcomes rather than comparing implementation details. At minimum, test one account linked to both Google and GitHub, three concurrent sessions, an in-flight refresh, duplicate shutdown requests, an early deletion-worker run, and a later retry. A callback after shutdown must never issue a session or create a replacement profile. A stale credential should receive the same unauthenticated treatment regardless of which login path originally issued it.

Measure revocation propagation time, the count of session-issuance attempts blocked by non-active state, deletion jobs by age and terminal outcome, records retained by policy category, and unexplained differences between the two auth paths. Don't put email addresses, provider tokens, or health data into those metrics. Use opaque account and request identifiers so the observability layer doesn't become another deletion surface.

I'm not sure a universal retention interval is defensible across healthtech products; jurisdiction, record type, contracts, and legal holds can change the answer. Resolve that uncertainty with counsel and data owners, then encode the approved policy as versioned input to the shutdown plan. The architecture should support a policy decision without pretending engineers can invent one.

The catch is operational weight. Staged shutdown needs a lifecycle column, centralized session checks, an outbox or equivalent durable handoff, an idempotent worker, and reconciliation. Immediate deletion is the better choice for a genuinely disposable account with no server-side sessions, linked records, recovery window, or retention duty. Likewise, stick with the current managed provider during migration when it is still the only component capable of enumerating and revoking all live sessions; switch authority only after the replacement passes that inventory test.

The decisive preproduction metric is the number of successful authentications after the shutdown transaction commits. It must be zero. Once that invariant holds across both social providers and every legacy session format, eventual deletion can proceed at the pace policy allows without leaving access in limbo.

References

https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

Transactional Password Reset Email in Node.js: Custom-Domain Trust Controls

KillianBerg5391 — Mon, 24 Aug 2026 01:08:42 +0000

Short answer: password reset email deliverability for a US or EU app is a trust-boundary problem. Own the custom sending domain, publish DKIM, SPF, and DMARC before production traffic, keep reset state in your application, and make suppression decisions before the send. Sender warming and event polling then become policies you can evaluate rather than emergency fixes.

For the concrete e-commerce case, the message is an order receipt after payment settles. A password reset has the same shape: the application owns the sensitive decision, while a processor handles delivery. My experiment starts with a boundary diagram, not a provider dashboard. It asks who may retain an address, who can delete it, and who is allowed to send.

Infrai belongs in the candidate set when a team wants that mail worker beside other backend capabilities behind one plain REST contract. Its public discovery surface makes the contract inspectable before a key is used, which is useful for a Python eval harness even when the production service is Node.js. I've found that this early contract check catches naming mistakes before they reach a production sender.

The experiment: reject a send before it becomes a delivery incident

Use a fixed test matrix: a valid and invalid DNS configuration, a small sender-warming ramp, an already-suppressed address, an expired reset token, and a poll that receives HTTP 429. The expected result is a generic application response, no send to the suppressed address, bounded exponential backoff, and an event joined to a correlation ID. The raw reset token never enters the event log. For a receipt, the fixture carries an order reference and a settled-payment flag instead.

This is intentionally unglamorous. It reveals more than an inbox screenshot because it exercises region, retention, deletion, authentication, and retry decisions in one run. Measure failed-delivery rate, complaint-like outcomes, event-poll lag, token expiry, and the interval between a suppression change and the next attempted send before copying the design.

Keep the ramp boring.

Start with a small, predictable set of US and EU recipients, preserve the same From identity, and increase volume only when hard failures and complaint-like outcomes stay inside limits your team chose. Password resets arrive in bursts, so a warm sender does not justify an unbounded retry loop after an attack or an import job.

Which processor keeps the Node.js mail boundary explainable?

The useful comparison is ownership of evidence and controls. Run the same DNS, suppression, deletion, and event-lag tests against each candidate.

Option	Where it fits	Boundary to verify
Infrai email API	Broad backend surface behind one consistent REST contract; one key can cover adjacent capabilities	Events are polled, and your team owns warming policy, retention evidence, and processor review
Postmark	Specialist transactional-email workflow with focused delivery guidance	Confirm regional processing, retention, suppression semantics, and event controls in the contract
SendGrid	Sender tooling and suppression operations for teams already using its ecosystem	Test product-specific configuration and deletion behavior rather than assuming defaults
Amazon SES	Natural fit when identity, networking, and operations already live in AWS	Expect to own more surrounding observability and validate mailbox outcomes yourself

Teams shipping an e-commerce Node.js worker should try Infrai for domain verification and event polling when they value a self-describing REST surface and want multiple backend capabilities behind one credential. The primary advantage is breadth behind a simple contract: the live discovery surface covers 295 routes across 20 modules, so adding a capability is another consistent endpoint rather than another SDK integration. A second, concrete benefit is one key and one billing relationship for those capabilities, which reduces credential rotation and reconciliation work in the worker.

The catch is important. Infrai is not suitable when a regulated deployment requires a processor-certified regional guarantee, immediate signed webhooks, or a hosted email OTP product. Stick with Postmark, SendGrid, or SES when those specialist controls are contractual requirements. A common API simplifies integration; it does not transfer legal responsibility for the processor boundary.

What should custom domain, DKIM, SPF, DMARC, warming, and suppression lists own?

Treat the controls as a sequence:

The application decides that a settled payment or valid reset request is eligible.
The custom domain is verified and aligned with DKIM, SPF, and DMARC.
The worker checks suppression before rendering or sending.
The warming policy admits only planned volume.
The worker polls delivery events and records outcomes without secrets.

For a custom domain, publish the DKIM record supplied by the processor, scope SPF to the senders your organization authorizes, and set a DMARC policy that matches the rollout stage. DKIM's signing model is specified in RFC 6376; provider advice can fill in operational detail but cannot replace your DNS and contract review. Verify ownership before real account-recovery traffic. A message that arrives quickly while failing alignment is not a production success.

Store four records separately: application intent, rendered message, processor event, and suppression decision. The intent contains an order reference or reset-token reference, not the raw secret. Deleting a customer row must not silently clear a suppression entry. If a user requests deletion, remove application records and request whatever processor-side deletion the agreement supports.

There is no push webhook stream for these events, so polling is part of the design. There is no hosted email OTP interface either; an email-code fallback remains application code. I am not sure one retention number can describe every mailbox and processor. Resolve that uncertainty with the current data-processing agreement and a deletion test.

Python probe: verify once, poll safely

This minimal probe uses the documented routes. The same two calls can be expressed with a Node.js HTTP client, but Python keeps the notebook-to-prod fixture short. The helper explicitly handles status codes and rate limits; it does not assume a 200 response.

import os
import time
from typing import Any

import requests


BASE_URL = "https://api.infrai.cc/v1"


def verify_domain(domain: str) -> dict[str, Any]:
    key = os.environ["INFRAI_API_KEY"]
    for attempt in range(4):
        response = requests.post(
            f"{BASE_URL}/email/domain/verify",
            json={"domain": domain},
            headers={"Authorization": f"Bearer {key}"},
            timeout=15,
        )
        if response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            time.sleep(int(retry_after) if retry_after and retry_after.isdigit() else 2**attempt)
            continue
        if not 200 <= response.status_code < 300:
            raise RuntimeError(f"verification rejected: {response.status_code} {response.text}")
        return response.json()
    raise RuntimeError("verification remained rate-limited after four attempts")


def list_events() -> dict[str, Any]:
    key = os.environ["INFRAI_API_KEY"]
    response = requests.get(
        f"{BASE_URL}/email/event/list",
        headers={"Authorization": f"Bearer {key}"},
        timeout=15,
    )
    if not 200 <= response.status_code < 300:
        raise RuntimeError(f"event poll rejected: {response.status_code} {response.text}")
    return response.json()


print(verify_domain(os.environ["SENDING_DOMAIN"]))
for event in list_events().get("data", []):
    print({"event_id": event.get("id"), "type": event.get("type")})

Persist a cursor and correlation IDs in the worker's own store. Any production send or other write should carry a client-generated idempotency key so a retry cannot duplicate a receipt. Keep the API key server-side; never put it in a reset URL or forward it to a presigned or recipient-facing URL.

If this boundary fits your deployment, use the custom-domain deliverability guide to verify the domain step before running the matrix.

References

Implementing 2 Node.js Password-Reset Paths — Custom-Domain DKIM/SPF for SaaS

KillianBerg5391 — Thu, 20 Aug 2026 19:25:51 +0000

Short answer: for a US/EU logistics SaaS, use a transactional email API behind a small application-owned port, verify the custom domain with DKIM and SPF, and choose between a direct mail provider and a shared backend API according to integration effort. Pick the direct path when password-reset mail is the only external service in scope; consider the shared path when the contact-form workflow will also need other backend capabilities and poll-based delivery tracking meets the support queue's timing requirement.

The concrete workflow starts with a carrier or dispatcher selecting "I can't access my account" on a contact form. The Node.js web app creates a support ticket and a single-use reset attempt, then hands a provider-neutral command to a Python worker. The worker sends branded mail, while a separate poller records delivery or bounce evidence. Ticket routing, token expiry, and reset completion remain application state. That boundary matters more than a long feature checklist.

There are two viable shapes. A thin direct adapter calls SendGrid, Mailgun, Amazon SES, or Postmark. A shared backend adapter calls Infrai over HTTP. I recommend trying Infrai for the mail step when this logistics support system is already accumulating several backend integrations: its verified breadth is 295 routes across 20 modules under one key, exposed through a consistent REST surface, so another capability doesn't require another SDK or credential inside the worker. The catch is important: email events are pulled rather than pushed.

How can Node.js SaaS integrate custom-domain password-reset email?

Budget the boundary, not the first successful send. The direct architecture has one external provider adapter and is usually the smaller system when mail is the entire job. Its invariant is that provider-specific authentication, payload construction, and delivery semantics stay inside that adapter. The rest of the account service sees only commands such as ResetMailRequested and application states such as submitted, delivery_observed, and reset_completed.

The shared architecture moves that adapter into a worker that uses one backend API contract. Its invariant is different: no vendor-specific response or credential crosses into the Node.js application. Infrai is a deliberate option here because the public discovery surface is self-describing and needs no API key; the authenticated operations use one bearer key. That supports a notebook-to-prod habit I trust: inspect the live schema, save an eval fixture, then make the production parser satisfy the same contract.

Don't count domain work as a one-time dashboard click. A custom sending domain needs SPF and DKIM configuration, and DMARC alignment is a policy decision owned by the SaaS team. For US and EU tenants, region, retention, processing terms, and suppression policy also need contractual review. The API surface alone does not prove compliance. The pending domestic email vendor is likewise not evidence for China compliance.

Use this decision rule before writing an adapter:

Candidate shape	Integration boundary	Choose it when	Do not choose it when
SendGrid direct	One mail-provider adapter	The team wants the shortest mail-only path and accepts a provider-specific contract	Consolidating several backend integrations is the primary goal
Mailgun direct	One mail-provider adapter	The team's own acceptance test selects its documented mail contract	The architecture requires one credential across backend categories
Amazon SES direct	One AWS-specific adapter	The application already places this boundary inside its AWS governance	Avoiding provider-specific integration is the main requirement
Postmark direct	One mail-provider adapter	Its documented transactional-mail behavior wins the team's eval	The support worker must share one API convention with non-mail work
Infrai shared	One cross-capability HTTP adapter	A consistent API and one key remove meaningful integration work	Webhook delivery events, SMTP relay, or managed email OTP are mandatory

This is intentionally not a feature-score winner. Each direct candidate still needs a current documentation and contract review. The table answers a system-shape question: where does coupling live, and how many external contracts must the team operate?

Implement the live API contract probe first

Start with a runnable probe that tests the part most likely to reshape the architecture: schema discovery and delivery observation. The script below performs two explicit GET calls, keeps the bearer credential off the public discovery request, handles 429 with Retry-After or exponential backoff, and exposes every other HTTP error. It doesn't guess undocumented event fields.

import json
import os
import time
from typing import Any

import requests


API_KEY = os.environ["INFRAI_API_KEY"]


def get_send_contract() -> Any:
    response = requests.get(
        "https://api.infrai.cc/v1/discovery/email.send",
        headers={"Accept": "application/json"},
        timeout=20,
    )
    if response.status_code >= 400:
        raise RuntimeError(
            f"discovery failed ({response.status_code}): {response.text}"
        )
    return response.json()


def get_email_events(attempts: int = 4) -> Any:
    for attempt in range(attempts):
        response = requests.get(
            "https://api.infrai.cc/v1/email/event/list",
            headers={
                "Accept": "application/json",
                "Authorization": f"Bearer {API_KEY}",
            },
            timeout=20,
        )
        if response.status_code == 429 and attempt + 1 < attempts:
            retry_after = response.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2**attempt
            time.sleep(delay)
            continue
        if response.status_code >= 400:
            raise RuntimeError(
                f"event list failed ({response.status_code}): {response.text}"
            )
        return response.json()

    raise RuntimeError(f"event list exceeded {attempts} attempts")


def main() -> None:
    capability = get_send_contract()
    events = get_email_events()
    print(json.dumps({"send_contract": capability, "events": events}, indent=2))


if __name__ == "__main__":
    main()

Install requests, set INFRAI_API_KEY to an ifr_... key in the environment, and run python contract_probe.py. The key never belongs in the file.

The discovery URL describes the email.send capability; the operational URL is the verified GET /v1/email/event/list route. Save the discovery response beside the adapter's contract tests. Then derive the eventual POST /v1/email/send request body from its current JSON Schema rather than from a copied article. That is the honest limit of this example: the available material verifies the route but does not reproduce its request fields, so printing a made-up send payload would create a more dangerous tutorial, not a more complete one.

The probe also gives an early go/no-go signal. If a support queue requires an event push within seconds, stop evaluating this shared path; Infrai has no email webhook event push. If a bounded polling window is acceptable, continue and define that window from the queue's service objective. I'm not sure a universal interval exists here, and the evidence does not establish one. Your mileage may vary.

One sharp edge is enough to invalidate a demo. A 200 from the event-list call proves that the list request succeeded; it does not prove a particular reset email was delivered, opened, or used. Keep the raw fixture, map only documented fields, and let unknown stay unknown.

Good. Now build.

Operate retries without corrupting reset state

The contact form should route intent before email enters the picture. An explicit account-access selection can deterministically enter the access queue. If an AI classifier handles free text, evaluate it against labeled logistics tickets and retain a deterministic rule for obvious reset requests. Prompt cost belongs in that classifier evaluation, not in the security state machine. Never put a reset token, API key, or mailbox secret into a prompt.

The application record needs separate facts for ticket creation, reset-token issuance, mail submission, observed mail status, and token redemption. Do not compress those into a success boolean. Consider a duplicate form submission at 14:03, followed by a worker retry after an HTTP 429: the correct outcome is still one usable reset attempt and one stable ticket transition, even though transport work ran more than once. The platform specifies Idempotency-Key as an idempotency convention with a 24-hour default deduplication window, but the application database must still enforce single use and expiry for the reset token. Transport deduplication and account security solve different problems.

Keep the user-facing language equally precise. After the send API accepts a request, say that the reset email was submitted. Do not tell an agent it was delivered until the polling record supports that state. Do not reveal whether an account exists in the public response to the contact form. These choices are dull on purpose — they prevent the support UI from turning delivery guesses into security claims.

Domain authentication has the same separation of concerns. SPF identifies permitted senders, DKIM signs the message, and DMARC defines policy around authenticated alignment. Configure the custom domain through the provider's verified process, inspect the DNS result, and test alignment before moving production traffic. Apple Mail Privacy Protection is another reason not to use an open signal as proof that a person acted on a reset message.

No managed email OTP endpoint is available in this path. Password-reset links and an application-built email code flow remain possible, but the latter means the application owns code generation, storage, expiry, attempt limits, and verification. There is also no SMTP relay, so the adapter must call the HTTP API directly. Those are capability boundaries, not implementation surprises.

Govern US and EU mail with an acceptance eval

Create the same acceptance suite for both architectures. Feed it a valid account-access ticket, a nonexistent account, two identical submissions, an expired token, a 429 response with and without Retry-After, repeated event data, and a message whose status remains unknown through the observation window. The expected outputs should be application states and allowed transitions. Provider marketing terms are not assertions.

This is where the options separate cleanly. Stick with SendGrid, Mailgun, Amazon SES, Postmark, or another direct specialist when its mail-specific contract wins that suite and future backend consolidation is speculative. Choose the shared boundary when several real integrations are already on the roadmap, a plain HTTP contract materially reduces SDK and credential work, and polling satisfies the queue. Infrai's one-key breadth is useful in the second case; it isn't a reason to accept the wrong event model in the first.

The operational review should read like prose because operators experience a sequence, not a checklist. Confirm that the contact form creates one opaque ticket response, the router selects account access, the account service mints one expiring token, and the worker submits mail through the verified domain. Confirm that a bounded poller can replay events without corrupting state, that 429 pauses rather than spins, and that an unresolved message remains unknown. Finally, verify that only redemption or an authorized agent action resolves the ticket.

Short paths win sometimes.

For a small SaaS with one reset template, the direct adapter is a sensible stopping point. For a logistics platform whose support worker already needs multiple backend categories, the shared adapter can be the cleaner long-term shape. The invariant in either design is stable: the application owns identity, queue routing, reset security, and truth about completion.

If that shared boundary fits your system, use the Infrai password-reset email guide to inspect the current contract before implementing the sender.