You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently RecordsSubscribe does not check if a subscription is valid beyond when it is processed. This means that while the subscription is live, if something changes that would make the subscription invalid (ex. delete of protocol role, or revocation of a grant) the subscriber will still receive updates until they close the connection.
We would like to proactively evict these subscriptions where possible, or potentially re-authorize on a TTL if evicting is too cumbersome.
The text was updated successfully, but these errors were encountered:
Can you just drop any connections associated with a revoked subscription?
Well the subscription itself is not revoked, but rather a user's protocol role may be deleted, or a grant which invalidates the subscription authorization.
But yeah that's the idea, is to stop emitting messages to the handler provided.
The dwn-sdk-js package itself keeps this transport agnostic, so the dwn-server itself will deal with dropping web socket connections if necessary.
Nothing too complex, just breaking it out into separate issues so that we can prioritize and chunk out subscriptions into smaller PRs.
This PR builds on top of the existing `EventStream` and adds a subscription specifically for the `Records` interface which follows similar rules as those for `RecordsQuery`.
Currently the subscription does not evict or re-authorize subscriptions after the initial processing of the message. So if a revocation of permissions happens after the subscription is live, the user will continue getting notified until they close the connection.
This will be addressed in a separate PR to keep things more concise and easier to follow. #668
Currently
RecordsSubscribe
does not check if a subscription is valid beyond when it is processed. This means that while the subscription is live, if something changes that would make the subscription invalid (ex. delete of protocol role, or revocation of a grant) the subscriber will still receive updates until they close the connection.We would like to proactively evict these subscriptions where possible, or potentially re-authorize on a TTL if evicting is too cumbersome.
The text was updated successfully, but these errors were encountered: