Skip to content

Delete managed tokens with smartphone containers - #540

Open
frankii91 wants to merge 1 commit into
privacyidea:masterfrom
frankii91:fix/cascade-container-deletion
Open

Delete managed tokens with smartphone containers#540
frankii91 wants to merge 1 commit into
privacyidea:masterfrom
frankii91:fix/cascade-container-deletion

Conversation

@frankii91

Copy link
Copy Markdown

Summary

Make smartphone-container removal an atomic local lifecycle operation:

  • remove every token managed by the container before removing the local container record;
  • do not offer a second choice that leaves those tokens behind as unmanaged local tokens;
  • silently reconcile local state when privacyIDEA reports that the container no longer exists or is no longer registered;
  • keep the single destructive confirmation for an explicit user-initiated container deletion.

Problem

A smartphone container is the synchronization and management boundary between privacyIDEA and the authenticator. Previously, deleting or unregistering that boundary could remove only the local container record while retaining the tokens that belonged to it. Likewise, when synchronization received terminal responses indicating that the container was missing (601) or no longer registered (3001), the app asked the user whether to accept the server-side state.

This can turn server-managed tokens into local orphans:

  • the server has removed or invalidated the management boundary;
  • the app can no longer receive authoritative lifecycle updates for its former members;
  • token secrets can remain on the device because the user declined cleanup or selected "Only container".

That leaves the app in a state which no longer reflects the administrator-controlled server state.

Why cascading cleanup is preferable

Container membership defines which local token material is managed by that server container. Once the container registration is gone, retaining its former members locally is not a meaningful synchronization state. The client should therefore treat removal of the container and removal of its managed local tokens as one lifecycle operation.

This also makes server-side administration deterministic:

  • deleting a container with its tokens removes the corresponding local managed state;
  • deleting or unregistering the container cannot leave stale local credentials behind;
  • moving a token to another registered container remains possible: synchronization through that destination container can deliver it again under the new management boundary.

The change does not delete tokens on the privacyIDEA server. Server-side deletion, reassignment, and container membership remain controlled by the administrator. It only reconciles the local projection with the authoritative container lifecycle.

Implementation

  • Delete all locally managed members of the container, including offline tokens.
  • Verify that the members were removed before deleting the local container record.
  • If local token deletion fails, keep the container record so cleanup can be retried and the token is not orphaned.
  • Preserve unrelated and locally managed tokens.
  • Handle terminal resourceNotFound and containerNotRegistered synchronization results with silent local cleanup.
  • Continue surfacing transient network, HTTP, and unknown server errors as before.
  • Replace the nested "Only container" / "Delete all" choice with one clear confirmation explaining that the container and its tokens will be removed from the app.
  • Remove obsolete dialog code, tests, and localization keys.

Validation

  • Targeted notifier and container-dialog tests: 32 passed
  • Full Flutter test suite: passed
  • git diff --check: passed
  • Targeted analysis of the changed Dart files: no errors or warnings; only three pre-existing style infos in the notifier constructor
  • Full-project analysis remains at the upstream baseline: one warning in unchanged lib/model/token_folder.dart plus informational diagnostics

Regression coverage includes:

  • removing all managed tokens before the container, including offline tokens;
  • preserving unrelated tokens;
  • retaining the container when token removal fails;
  • silent cleanup after a manual synchronization reports a missing container;
  • keeping only one confirmation in the user-initiated deletion flow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant