You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We’ve seen a number of mysterious safe-sessions mismatches that appear to occur in close conjunction with an SSO login. We were able to reproduce this by deleting just the session cookie and then logging into a different account.
We’ve also seen some nginx logs that suggest that every once in a while someone loses a session cookie for no apparent reason; this may just be browser gremlins.
The mismatch occurs when an MFE is loaded; the MFE sends both JWT and session cookie to the LMS; the LMS first loads the user from the session and then the DRF middleware replaces the user with the one listed in the JWT.
Hypotheses
Somewhere in the TPA login flow, we think something is detecting valid JWT cookies (and not noticing that they’re for the wrong user) and therefore chooses not to “refresh” them (set new ones). Note that with missing or garbage JWT cookies, this bug does not happen – TPA login instead creates new (matching) JWT cookies.
We are not prioritizing this because we think the issue is: 1) rare, 2) appears to require client misbehavior, and 3) probably only creates annoyance for the one user. Could only be a security issue on a shared computer in some very unusual circumstances.
[idea] We might be able to add detection code in a response middleware that would log a warning or set an attribute when a session cookie is sent (for a non-anonymous session), but no corresponding JWT cookie is sent.
We’ve seen a number of mysterious safe-sessions mismatches that appear to occur in close conjunction with an SSO login. We were able to reproduce this by deleting just the session cookie and then logging into a different account.
We’ve also seen some nginx logs that suggest that every once in a while someone loses a session cookie for no apparent reason; this may just be browser gremlins.
Reproduction
The mismatch occurs when an MFE is loaded; the MFE sends both JWT and session cookie to the LMS; the LMS first loads the user from the session and then the DRF middleware replaces the user with the one listed in the JWT.
Hypotheses
Somewhere in the TPA login flow, we think something is detecting valid JWT cookies (and not noticing that they’re for the wrong user) and therefore chooses not to “refresh” them (set new ones). Note that with missing or garbage JWT cookies, this bug does not happen – TPA login instead creates new (matching) JWT cookies.
Note: This ticket was moved from this original 2U private-link ticket.
The text was updated successfully, but these errors were encountered: