Inconsistent login state vs guard(ed) routes

[nokrosis]

Guarded routes are validated by checking:

state.cognito.user !== null

However Dashboard on example app depends on:

state.cognito.state = CognitoState.LOGGED_IN

If a user logs in, the session data and user is saved in local storage. If the browser is closed and reopened, on entering the app, COGNITO_CONFIGURE action is fired which has the following code:

const configure = (state, action) => {
  // surprise side-effect!
  AWSCognito.config.region = action.config.region;
  const pool = new CognitoUserPool({
    UserPoolId: action.config.userPool,
    ClientId: action.config.clientId,
  });
  const user = pool.getCurrentUser();
  return Object.assign({}, state, {
    config: action.config,
    userPool: pool,
    user,
  });
};

When calling const user = pool.getCurrentUser(); cognito recovers the user from local storage, turning state.cognito.user !== null however, state.cognito.state is not updated to CognitoState.LOGGED_IN which turns the app on an undesired state:

1. On one side, the user is presented the Login Form as if it was not logged-in, because state.cognito.state !== CognitoState.LOGGED_IN

2. By the other side, the user CAN access guarded routes since state.cognito.user !== null

I think CognitoState should be updated accordingly if const user = pool.getCurrentUser(); has a valid user/session, or else what solution do you suggest to handle these states?

[jdalegonzalez]

This guard is also a problem when you attempt to login but fail. You have a non-null user object due to the attempt but your state is not "logged-in". If you're using a "not-logged-in" guard (b/c you don't want someone to hit the register/forgot password/whatever page when they're already logged in, the guard inappropriately fails.