While writing a web service accessed by web browsers, a co-maintainer suggested that we allow users to choose to log in to one session without using cookies. (Using hidden HTML forms is something else that we've considered but I'm not very keen on the idea. JavaScript is not acceptable.)
Using the Go standard library's HTTP server or perhaps other mechanics, while setting Connection: keep-alive, is it possible to identify which network connection an incoming request originated from?
- Storing a pointer to
http.Request.TLS(atls.ConnectionState) won't work because its memory could be freed and the address could be reused, making it possible to hijack sessions. - I don't see useful values in
http.Request.
It's definitely possible to implement this by accepting requests as a plain TCP/TLS/etc connection, store some information, and construct the http.Requests myself; but that seems like quite a pain.
While writing a web service accessed by web browsers, a co-maintainer suggested that we allow users to choose to log in to one session without using cookies. (Using hidden HTML forms is something else that we've considered but I'm not very keen on the idea. JavaScript is not acceptable.)
Using the Go standard library's HTTP server or perhaps other mechanics, while setting Connection: keep-alive, is it possible to identify which network connection an incoming request originated from?
- Storing a pointer to
http.Request.TLS(atls.ConnectionState) won't work because its memory could be freed and the address could be reused, making it possible to hijack sessions. - I don't see useful values in
http.Request.
It's definitely possible to implement this by accepting requests as a plain TCP/TLS/etc connection, store some information, and construct the http.Requests myself; but that seems like quite a pain.
- Does your API client is sending any traking information? There is no continuity in HTTP requests, so you can't track them without additional tracking information (e.g. headers) – Justinas Commented 2 days ago
- 1 Shared proxies exist. Just because two requests arrive on the same TCP connection does not mean they originate from the same user/device/browser. – Peter Commented 2 days ago
- 1 Note that the runtime does not free and reuse memory when the application has an active reference to the memory. – Thundercat Commented 2 days ago
- 1 @RunxiYu Your application's reference to the memory prevents the GC from reclaiming and reusing the memory. Close on a TLS connection does not directly free memory. Your reason for not storing a pointer is invalid. – Thundercat Commented 2 days ago
- 1 @RunxiYu, "storing a pointer to" is a reference which will prevent GC. If you store a pointer to the TLS object it cannot be collected, meaning the concern of "the address could be reused, making it possible to hijack sessions" is not possible. – Mr_Pink Commented 2 days ago
1 Answer
Reset to default 1I don't think that the idea behind the question even works, which means that it will also not work with net/http, no matter what features it offers. The rationale for my doubt:
- A browser opens multiple HTTP/1 connections even with HTTP keep-alive in order to send requests in parallel (HTTP/1 keep-alive can only to multiple requests after the other).
- A TLS session can span multiple TCP connections, but only if both sides support session resumptions.
This means you cannot really replace a HTTP session with "same TCP connection" or "same TLS session". Additionally even with HTTP keep-alive an idle TCP connection is closed after a while, loosing the "session".
All of this is independent from the library or programming language used.
Thus, use HTTP cookies to keep a session at the HTTP level. That what they were invented for in the first place. All the bad reputation is only because "maintaining a session" can also be misued for tracking users etc. But this is also true with other session mechanisms.