v0.47.2

XRouter's web dashboard keeps working after you log in to DAPPS

On a node running both, logging in to the DAPPS dashboard made the XRouter web dashboard answer "HTTP error 400 - Bad Request" (or drop the connection on XRouter 505c) until you cleared the browser's cookies (#248).

Browsers send a host's cookies to every port on that host, so XRouter was receiving DAPPS's cookies too, and together they were just over the longest header line XRouter accepts. DAPPS's cookies are now about a sixth smaller and well under that limit:

• Cookies are sealed with AES-256-GCM instead of AES-CBC + HMAC. That is the same strength or better, with less overhead.
• The antiforgery cookie is now called dapps.af, and the old long-named one is removed.

You stay logged in across the upgrade. Your next page load swaps in the smaller cookies, and XRouter's dashboard works again without clearing anything. XRouter's limit is reported upstream as packethacking/xrouter-container#30.

Probe candidates use the right port

Also in this release (it was numbered 0.47.1 on master but never published on its own): a station learned from a neighbour's peers list was probed on the neighbour's port number instead of our own port to that neighbour. On XRouter every such probe failed with "RHP error 10: Invalid port". Candidates now use the port their neighbour answered on, and ones already stored with the wrong port are corrected (#246).

Upgrading

• Nodes upgrade independently. Nothing changes on the air, and there is nothing to configure.
• The first start after upgrading writes one new data protection key next to the existing ones.

Known issues

• Other web apps on the same host can still push XRouter's dashboard over its limit with their own cookies. To keep them apart, open DAPPS and XRouter under different host names (for example, one by IP address and one by name).