Map and Scout access may remain active after user authorization is revoked

[Mygod]

Description

A user continued making map and Scout requests after their map access had been revoked.

Revocation worked correctly in a control test using a separate account: the client immediately displayed the no-access message. The affected user, however, remained active for more than an hour.

Expected behavior

Once a user's authorization is revoked, their existing sessions and connections should stop being able to access protected map and Scout functionality.

Actual behavior

ReactMap logs continued showing activity associated with the revoked user:

• A PokemonIVs request approximately every minute.
• Scout requests whenever the Scout cooldown reached zero.
• Activity continued for at least 1.5 hours after revocation.
• Restarting or temporarily stopping the map did not appear to resolve it.
• Rotating sessionSecret, thereby invalidating every session, stopped the activity.

Reproduction

The problem has not been reproduced through the normal browser flow.

Known sequence:

1. Give a user map access.
2. The user signs in and uses map/Scout functionality.
3. Revoke the user's map access.
4. Observe whether requests associated with that user continue appearing in ReactMap logs.

A separate test account was denied immediately, suggesting the problem may require a particular session state, client behavior, or request path.

Impact

A revoked user may retain access to protected data and expensive Scout operations. Administrators currently have no reliable targeted way to stop the activity and may need to invalidate every user's session.

Investigation notes

The requests appeared in ReactMap logs, but the precise path and cause are not yet known.

Possibilities to investigate include:

• A permission snapshot retained by an existing session.
• A session that is not removed by the normal revocation path.
• An already-open connection continuing to operate.
• A non-browser client reusing valid session credentials.
• Direct access to another backend endpoint.

These are hypotheses only. The available evidence does not establish a direct Dragonite bypass or a particular exploitation method.

The original production session and relevant server logs should be preserved privately if possible.

Resolution criteria

• Revoking a user denies their next protected request.
• Existing cookies cannot retain access after revocation.
• Existing WebSocket or subscription connections cannot continue receiving protected data.
• Administrative and provider-driven revocation behave consistently.
• Revocation can target the affected user without invalidating every other session.
• Automated coverage reproduces the failure through an actual request or connection rather than asserting database state alone.