|(require koyo/continuation)||package: koyo-lib|
Continuations in a web context are super valuable when it comes to quickly prototyping certain functionality. However, because it stores continuation ids within URLs, the web server is succeptible to session hijacking. This is by design. For some use cases it makes sense to allow users to share their URLs and have someone else be able to pick up from where they left off. In most web applications, though, that’s not what you want.
Let me illustrate the issue with an example. Say you have an e-commerce website and you implement your "add to cart" buttons using continuations. If you don’t protect your continuations, then a user could copy the URL for that button and give it to someone else; that other person would then inherit all of the state associated with that continuation. You might think that your users are unlikely to do that, but there are cases, such as via Referer headers, in which browsers can leak information about URLs in a web application.
To guard against the aforementioned issues, this module provides variants of the web server’s continuation-related functions that protect themselves against being hijacked. They do this by associating a random session cookie with each continuation that is captured. When a continuation is called and the visitor’s session does not contain said cookie, current-continuation-mismatch-handler is run instead of the target continuation function.
(current-continuation-key-cookie-path path) → void? path : path-string?
(current-continuation-key-cookie-secure? secure?) → void? secure? : boolean?
If you install a custom mismatch handler, you must avoid modifying the user session within it. The session that will get modified is the session of the original user, not of the "attacker", which is probably not what you want.
Without this, all protected continuations will fail out so don’t forget to add it to your middleware stack.
Middleware that themselves wrap wrap-protect-continuations will wrap the mismatch handler. This means you have to be careful not to wrap the middleware inside other middleware that modify the user session. Nor should your mismatch handler modify the session, because the session it modifies will be the one of the original user, not the "attacker."