Here’s what “the great big hole” in this logic is going to turn out to be:   JSON-activity, spread out among a number of different servers in the usual manner, given this logic in the way that it is now constructed ... which stores the session information in the cookie.

The hole is probably one that occurs on is_forward, under load:   the server that handles the forwarded request is not the same one that handled the previous one, and the start_request whatever-it-is did not go off.   So, cached information is re-used, and sent to the client, where it cleanly replaces the previous state ... with someone else’s.

Fundamentally, the fly in this ointment is how-and-where the session state is stored.   It appears that in this module the “secure” session storage object is only used as a magic encoder/decoder “wring” ... which is “wrong.”   Under no circumstances may host-side state be stored on the client side, even if it is encrypted.   There is both a stale-data problem here on the client-side, and a race-condition problem on the server side, as well as ample opportunities for impersonatiion and other exploits.