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
{{ message }}
Repository navigation
Commit 6be2ca1
Browse filesBrowse the repository at this point in the historyBrowse files
feat(events): grade cross-tenant isolation via the fixture's tenant controls
The rule is that two tenants subscribing to the same `(name, arguments)` with
the same callback get distinct subscriptions, because the principal is part of
the key. A run authenticates as one principal for its lifetime, so the harness
could only ever supply one side of that comparison and the row reported
untestable.
A fixture MAY now register on another principal's behalf and answer whether a
given principal's subscription still exists. With both, the check does the
comparison the rule is about: same event, same callback, principal the only
thing that differs.
Two things are graded, and the second is the one that bites. Distinct ids show
the principal reached the key at all. A surviving subscription after the other
tenant unsubscribes shows the two are genuinely independent, which is what a
tenant would notice if it were not true — one tenant able to cancel another's
subscription.
askControl joins fireControl in helpers for the controls that answer with text
rather than just succeeding.
Servers without the controls are unaffected and keep reporting untestable, now
naming the two tools that would make the row gradeable.
Against mcpkit: events-webhook 17/23 to 18/23.
Refs #504
'Because the key includes `principal` and `delivery.url`, two distinct tenants subscribing to the same `(name, arguments)` get distinct subscriptions.';
`A run holds one principal, so the two-tenant case cannot be constructed. Needs a fixture exposing the \`${EVENTS_CONTROL_SUBSCRIBE_AS}\` and \`${EVENTS_CONTROL_SUBSCRIPTION_EXISTS}\` controls. The \`delivery.url\` half of the same rule is graded by sep-9999-subscribe-key-composition.`,
836
+
[EVENTS_SPEC_REF]
837
+
)
838
+
];
839
+
}
840
+
841
+
// Same event, same callback. The principal is the only thing that differs,
842
+
// which is what makes a shared id mean what it means.
errorMessage: `Subscribing as this run's own principal to the same event and callback failed with ${mine.error.code}${mine.error.message}, so the two subscriptions could not be compared.`
868
+
})
869
+
];
870
+
}
871
+
872
+
constmyId=mine.result.id;
873
+
if(myId===otherId){
874
+
return[
875
+
eventsCheck(id,description,'FAILURE',{
876
+
errorMessage: `Two principals subscribing to \`${name}\` with the same callback received the same subscription id (${myId}), so the principal is not part of the key. One tenant can address, refresh or cancel another's subscription.`,
877
+
details: {id: myId}
878
+
})
879
+
];
880
+
}
881
+
882
+
awaitconn
883
+
.request(EVENTS_UNSUBSCRIBE_METHOD,{id: myId})
884
+
.catch(()=>undefined);
885
+
constsurvived=awaitaskControl(
886
+
conn,
887
+
EVENTS_CONTROL_SUBSCRIPTION_EXISTS,
888
+
other
889
+
);
890
+
891
+
return[
892
+
survived==='true'
893
+
? eventsCheck(id,description,'SUCCESS',{
894
+
details: {mine: myId,other: otherId}
895
+
})
896
+
: eventsCheck(id,description,'FAILURE',{
897
+
errorMessage: `The two tenants received distinct ids, but unsubscribing \`${myId}\` also removed the other tenant's subscription, so they are not independent.`,
@@ -993,15 +1101,7 @@ export class EventsWebhookScenario implements ClientScenario {
993
1101
)
994
1102
);
995
1103
996
-
out.push(
997
-
untestableCheck(
998
-
'sep-9999-subscribe-cross-tenant-isolation',
999
-
'sep-9999-subscribe-cross-tenant-isolation',
1000
-
'Because the key includes `principal` and `delivery.url`, two distinct tenants subscribing to the same `(name, arguments)` get distinct subscriptions.',
1001
-
'A run holds one principal, so the two-tenant case cannot be constructed. The `delivery.url` half of the same rule is graded by sep-9999-subscribe-key-composition.',
0 commit comments