Christopher Lemmer Webber wrote on 09/01/2018 09:05 PM:
Waterken uses URI fragments to get around this in a secure way, since browsers do not transmit the URI fragment to the server:
There's lots of ways that URL fragment identifiers can leak from a browser, to untrustworthy parties, or to weaker storage, with all the cloudy/snoopy 'services' going on. I've also seen fragment identifiers in `Referer` fields of access logs.
Another way to get around this design problem would be to use cookies, maybe signed if necessary (not sure it would be, since a large opaque bearer token may be sufficient). I am not a huge fan of that design in some ways but it may be the best option available given the options available within the insecurity of modern web browser design.
I defer to the framework authors on this framework, but some generic Web approach, for the list...
Offhand, using large random cookie values for authentication tokens sounds plausible to me.
To be clear, I don't think that the cookie would reference server-side continuations (if that's the role of the URL query/parameters). Rather, the cookie could provide access control to a set of continuations (for a session or user), and each continuation would be associated with exactly-one authentication token (or with user or session ID, if you want to do it that way).
This authentication token doesn't have to be part of a login mechanism. For the appropriate HTTP request methods, you can use whatever cookie the browser sends, and, if no cookie is offered, do a redirect to set the cookie. If you do this without login, try to make cookie not expire, to avoid having to implement mitigating complexity to keep a user from suddenly losing access to their continuations. (If the cookie instead gets cleared by the browser for other reasons, like due to privacy settings for when closing the browser, or Ctrl-Shift-Del, at least the user is less likely to be surprised that their "session" is gone.)
Cookies go back to the early browser wars, and will work in almost all browser setups (even when disabling JS, disabling third-party cookies, not having a certain kind of HTML5 storage, a particular browser vendor deciding that a kind of local storage is very ephemeral). The Web is mostly funded by cookies. :)
Cookies are also pretty familiar, and still pretty simple, and might not confuse any demonstrative or pedagogic intent of academic work on the framework, compared to some other options.
(I suspect that HTTP Basic authentication, HTTP `POST` method `form` fields, HTML5 storage, and superbug trickery all have bigger downsides than cookies for this. But, I haven't used that particular framework in several years, so, without looking at it now, I could be missing a better opportunity.)
-- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
