Details
Added this code in web:
const getInitialReduxState = ( callServerEndpoint: CallServerEndpoint, ): (URLInfo => Promise<InitialReduxState>) => async urlInfo => { const response = await callServerEndpoint( 'get_initial_redux_state', urlInfo, ); return { navInfo: response.navInfo, <... omitted for brewity ...> keyserverInfo: response.keyserverInfo, }; };
called it and checked if it returned expected fields.
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
keyserver/src/responders/redux-state-responders.js | ||
---|---|---|
93 ↗ | (On Diff #30920) | Removed: let urlInfo = infoFromURL(decodeURI(req.url)); try { urlInfo = await validateInput(viewer, urlInfoValidator, urlInfo, true); } catch (exc) { // We should still be able to handle older links if (exc.message !== 'invalid_client_id_prefix') { throw exc; } } because urlInfo is just a normal input now. Handling old urls with old id schema will be handled in the later diffs |
204 ↗ | (On Diff #30920) | Previously we returned whole userStore with default inconsistencyReports: return { userInfos: hasNotAcknowledgedPolicies ? {} : userInfos, inconsistencyReports: [], }; |
316–319 ↗ | (On Diff #30920) | Previosuly: return { keyserverInfos: { [ashoatKeyserverID]: { cookie: undefined, sessionID, updatesCurrentAsOf, urlPrefix, connection: defaultConnectionInfo, lastCommunicatedPlatformDetails: null, }, }, }; Now we return only non-persisted, non-default field and only for the current keyserver. |
Looks like a straightforward change
Probably moving policies logic from the responder itself to a higher place where we just avoid returning anything will make this code simpler - but since this will change in the future anyway (ENG-4137) it's okay the way it is
keyserver/src/responders/redux-state-responders.js | ||
---|---|---|
4–6 ↗ | (On Diff #30920) | can be merged |
Probably moving policies logic from the responder itself to a higher place where we just avoid returning anything will make this code simpler - but since this will change in the future anyway (ENG-4137) it's okay the way it is
After we move the user data out of keyserver and into identity/backup restoration, we should be able to handle this endpoint like the rest.