Page MenuHomePhabricator

[lib] Introduce relyingOnAuthoritativeKeyserver constant
ClosedPublic

Authored by ashoat on Mar 3 2024, 9:06 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, May 13, 12:15 AM
Unknown Object (File)
Apr 21 2024, 3:30 AM
Unknown Object (File)
Apr 17 2024, 12:49 AM
Unknown Object (File)
Apr 13 2024, 4:24 PM
Unknown Object (File)
Apr 4 2024, 6:43 PM
Unknown Object (File)
Mar 28 2024, 1:15 PM
Unknown Object (File)
Mar 12 2024, 3:24 PM
Unknown Object (File)
Mar 8 2024, 12:12 PM
Subscribers
None

Details

Summary

This diff starts the process of splitting usingCommServicesAccessToken into three:

  1. usingCommServicesAccessToken: flipped to true for identity service launch
  2. supportingMultipleKeyservers: whether the app works with multiple keyservers, which relies on Tunnelbroker to sync data (eg. keyservers and users) and the backup service to restore that data
  3. relyingOnAuthoritativeKeyserver: whether the app needs to have a cookie with the authoritative keyserver in order to be considered logged in

These will all be separate launch processes, so I figured it made sense to have three separate constants.

In this diff I introduce relyingOnAuthoritativeKeyserver. In the following diff I'll update reducers to use relyingOnAuthoritativeKeyserver to decide whether to log the user out during a SET_NEW_SESSION with cookieInvalidated.

Depends on D11227

Test Plan

I used this test plan for the whole stack: https://gist.github.com/Ashoat/75ab690d5c53cdd68a51b02e03e27c58

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Mar 5 2024, 6:30 AM
lib/components/keyserver-connection-handler.js
180 ↗(On Diff #37761)

I should add relyingOnAuthoritativeKeyserver here too

Add relyingOnAuthoritativeKeyserver condition to logout when we fail to auth with authoritative keyserver