Fix session timeout redirect

[cKellyDesign]

Currently if a user tries to open oAuth2-protected client sites "nothing happens" unless the site is opened in a private browsing window.

(Note: this is not a fire because production products are still available via private browsing, but this is definitely not acceptable long-term solution)

Under the hood, the Gisida application is checking for session expiration information saved in localStorage to determine if the present auth cookies are still valid. If the app finds expired session information in localStorage the app redirects to /login which is not actually rendering the Login component.

Furthermore, this approach is flawed because the app is checking for very generic session information and is easily contaminated by other client sessions.

Suggested Fix(es)

1. Audit client sites to understand the breadth of this bug
2. Remove the auth cookie and session info in localStorage when a session is expired
3. Namespace the cookie and session expiration info in localStorage
4. Render the Login component after redirecting to /login
5. Tag a new minor version release
6. Update effected client sites and re-deploy

Effected Clients

• [x] Idai Recovery Zimbabwe (production site | repo)
• [x] hellomwana-zimbabwe

[cKellyDesign]

@kahummer @kelvin-muchiri @ciremusyoka - please add any other effected clients that you know of to the description.

[cKellyDesign]

cc @akahure @engwiri @ukanga

[akahure]

@cKellyDesign thanks, I would flag this as a high priority since the clients have been accessing it using the normal browser and now to provide different instructions is involving from a support perspective. I have already started to receive a number of queries around the site being inaccessible. Given the steps outlined

• What changed on the site, because last week it was fine
• What would it take to fix it from an LOE perspective
• Why have other clients not been affected, is tied to a recent deployment

[akahure]

@JohnMwashuma not sure if this is tied to the same Cache issue experienced by grp for Oauth 2

[cKellyDesign]

not sure if this is tied to the same Cache issue experienced by grp for Oauth 2

I don't think this is related, don't think we're sharing much in the way of code between those repos

What changed on the site, because last week it was fine Why have other clients not been affected, is tied to a recent deployment

There was a change in Gisida React which is adding a redirect to the page, if some clients were bundled using an older version of the App component then I don't think they'll experience this issue.

[JohnMwashuma]

@JohnMwashuma not sure if this is tied to the same Cache issue experienced by grp for Oauth 2

No it's not

[cKellyDesign]

@akahure I'm going to close this issue b/c we have a core fix for this in gisida (v1.4.0) and gisida-react (v1.4.1) and have implemented the fix in prioritized repos.

I think if we find this bug in other client repositories we can create / assign tickets to implement the fix as it comes up. For posterity, the fix should look like:

// client index.js
const clientId = <some-super-secret-client-id-NOT-for-public-repos>;
const LoginView = <Login oauthclientID={clientId} />;

const authC = (path) => {
  if (!isLoggedIn()) {
    SupAuth.defaultUnSupAuthZ()
    return false;
  }
  return SupAuth.defaultSupViewAuthC(path);
}

ReactDOM.render(
  <Provider store={store}>
    <Router.Wrapper>
      <Router.PrivateRoute
        exact
        path="/"
        auth={authC}
        component={() => AppView}
      />
      <Router.PublicRoute path="/login" component={() => LoginView} />
      <Router.PublicRoute path="/callback" component={() => CallbackView} />
    </Router.Wrapper>
  </Provider>,
  rootElement
);