* Add type-safe wrapper types to deployement_cfg
* Before deleting redundnat macros
* Store error messages as data
* Significant progress on type safety
* Add type safety to RedisConfig
* Refactor configuration
* Fix bug with incorrect Host env variable
* Improve logging of REDIS_NAMESPACE
* Update test for Postgres configuration
* Conform Redis config to Postgres changes
Remove Postgres SSL support, which was not working at the moment and
was preventing flogatt from running on servers without openssl.
We should re-enable SSL support at a later time.
* Refactor organazation of SSE
This commit refactors how SSE requests are handled to bring them into
line with how WS requests are handled and increase consistency.
* Add websocket tests
* Bump version to 0.2.0
Bump version and update name from ragequit to flodgatt.
* Add test for non-existant endpoints
* Update documentation for recent changes``
* Upgrade postgres dependency to support ssl
* Clean up configuration code
* Add support for SSL with postgres [WIP]
* Add unit tests with mock Postgres
This commit adds several aditional Postgres config options, such
as PORT, USER, DB_NAME and similar. It also relocates the .env
file so that it will be picked up even if flodgat isn't run from
the src/ directory.
This commit stores each message received from Redis as a growable string
rather than in a buffer of fixed size. This allows the server to
receive messages of any length.
Previously, the access token needed to be passed via the query string;
with this commit, the token can be passed *either* through the query
string or the Sec-WebSocket-Protocol header.
This was done to correspond to the changes made to the streaming.js
version in [Improve streaming server security](https://github.com/tootsuite/mastodon/pull/10818).
However, I am not sure that it *does* increase security; as explained
at <https://support.ably.io/support/solutions/articles/3000075120-is-it-secure-to-send-the-access-token-as-part-of-the-websocket-url-query-params->,
there is generally no security advantage to passing sensitive information
via websocket headers instead of the query string—the entire connection
is encrypted and is not stored in the browser history, so the typical
reasons to keep sensitive info out of the query string don't apply.
I would welcome any corrections on this/reasons this change improves
security.