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
No Lint Coverage - Unit
No Test Coverage
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.