Change Details

`SessionProvider::provideSessionInfo()` returns null if the session credentials are invalid. But it also returns null if there are no session credentials at all. So there is no way to signal "session credentials are invalid and should be cleared" (ie. SessionManager should unpersist the session). This hasn't come up before, because 1) when `provideSessionInfo()` does return a session and it is found invalid during the store check (`SessionManager::loadSessionInfoFromStore()`), SessionManager does unpersist, and that's usually how it goes for cookie-based sessions; 2) most immputable session providers cannot persist / unpersist anyway, 3) when `provideSessionInfo()` returns null, we end up with an empty session, and usually CookieSessionProvider (or its CentralAuth version) will be called to provide an empty session, which is basically the same as unpersisting (it will delete the session cookies it knows about). But BotPasswordSessionProvider does persist/unpersist, and cannot handle empty sessions so that will be done by CookieSessionProvider, meaning when something (such as the session JWT added in T415007) is invalid and `BotPasswordSessionProvider::provideSessionInfo()` returns null, the `<wiki>_BPsession` cookie won't get cleared. Steps to reproduce: * enable JWT cookies for bot password sessions * set up a bot password and log into it * modify the JWT to e.g. contain an invalid issuer * send an API request Expected: request is seen as anonymous, `sessionJWT` and `<wiki>_BPsession` cookies get deleted Actual: request is seen as anonymous, `sessionJWT` cookie gets deleted but `<wiki>_BPsession` cookie doesn't (so the next request will not be anonymous)

`SessionProvider::provideSessionInfo()` returns null if the session credentials are invalid. But it also returns null if there are no session credentials at all. So there is no way to signal "session credentials are invalid and should be cleared" (ie. SessionManager should unpersist the session). This hasn't come up before, because 1) when `provideSessionInfo()` does return a session and it is found invalid during the store check (`SessionManager::loadSessionInfoFromStore()`), SessionManager does unpersist, and that's usually how it goes for cookie-based sessions; 2) most immutable session providers cannot persist / unpersist anyway, 3) when `provideSessionInfo()` returns null, we end up with an empty session, and usually CookieSessionProvider (or its CentralAuth version) will be called to provide an empty session, which is basically the same as unpersisting (it will delete the session cookies it knows about). But BotPasswordSessionProvider does persist/unpersist, and cannot handle empty sessions so that will be done by CookieSessionProvider, meaning when something (such as the session JWT added in T415007) is invalid and `BotPasswordSessionProvider::provideSessionInfo()` returns null, the `<wiki>_BPsession` cookie won't get cleared. Steps to reproduce: * enable JWT cookies for bot password sessions * set up a bot password and log into it * modify the JWT to e.g. contain an invalid issuer * send an API request Expected: request is seen as anonymous, `sessionJWT` and `<wiki>_BPsession` cookies get deleted Actual: request is seen as anonymous, `sessionJWT` cookie gets deleted but `<wiki>_BPsession` cookie doesn't (so the next request will not be anonymous)

`SessionProvider::provideSessionInfo()` returns null if the session credentials are invalid. But it also returns null if there are no session credentials at all. So there is no way to signal "session credentials are invalid and should be cleared" (ie. SessionManager should unpersist the session). This hasn't come up before, because 1) when `provideSessionInfo()` does return a session and it is found invalid during the store check (`SessionManager::loadSessionInfoFromStore()`), SessionManager does unpersist, and that's usually how it goes for cookie-based sessions; 2) most immputable session providers cannot persist / unpersist anyway, 3) when `provideSessionInfo()` returns null, we end up with an empty session, and usually CookieSessionProvider (or its CentralAuth version) will be called to provide an empty session, which is basically the same as unpersisting (it will delete the session cookies it knows about). But BotPasswordSessionProvider does persist/unpersist, and cannot handle empty sessions so that will be done by CookieSessionProvider, meaning when something (such as the session JWT added in T415007) is invalid and `BotPasswordSessionProvider::provideSessionInfo()` returns null, the `<wiki>_BPsession` cookie won't get cleared. Steps to reproduce: * enable JWT cookies for bot password sessions * set up a bot password and log into it * modify the JWT to e.g. contain an invalid issuer * send an API request Expected: request is seen as anonymous, `sessionJWT` and `<wiki>_BPsession` cookies get deleted Actual: request is seen as anonymous, `sessionJWT` cookie gets deleted but `<wiki>_BPsession` cookie doesn't (so the next request will not be anonymous)