The Wire · Showcase
PHOENIX TIGHTENS LONGPOLL SECURITY WHILE ELIXIR FIXES SPEC BUGS ACROSS THE STACK
By RepoJournal · Filed · About Elixir & Phoenix
Phoenix is enforcing a hard cap on longpoll batch sizes to close a potential attack surface, and you need to know the upgrade path.
Phoenix shipped a breaking change that enforces a maximum of 100 entries per longpoll request [1], hardening against a known attack vector. The client has enforced this limit since 1.8.6, so if you're running older versions with heavy longpoll traffic, upgrade to 1.8.6 or 1.8.7 first before jumping to the latest. On the auth front, Phoenix now lets authToken be a function instead of a static value [2], giving you a cleaner path to refresh tokens on reconnect without mutating the socket directly. Meanwhile, Elixir fixed a spec bug in File.copy/3 [4] that was incorrectly excluding 0 as a valid return value, and Ecto patched wrong placeholder numbering when using fragment sources with schemas [3], a subtle bug that would break parameterized queries in edge cases.
One email a day. Unsubscribe in one click.
Keep up with Elixir & Phoenix in about 3 minutes a day: what actually shipped — the commits, pull requests, releases, and security advisories that matter.
One email a day. Unsubscribe in one click. Read a past issue →
Action items
- → If running Phoenix with heavy longpoll load, stage upgrade to 1.8.6 or 1.8.7 first, then move to latest phoenixframework/phoenix [plan]
- → Update Ecto to pick up the fragment placeholder fix elixir-ecto/ecto [plan]
- → Migrate authToken to function-based approach for cleaner token refresh phoenixframework/phoenix [monitor]
References
- [1] Enforce longpoll batch size phoenixframework/phoenix
- [2] Allow authToken to be a function ↗ phoenixframework/phoenix
- [3] Fix wrong placeholder numbering when a `from` source is a `{fragment, schema}` tuple ↗ elixir-ecto/ecto
- [4] Fix spec of `File.copy/3` ↗ elixir-lang/elixir