A transport on the exit that hit SmartCaptcha or a login wall could only
report it to a local IPC socket on the exit host, where normally no app
is listening, so the exit's side of that carrier stayed down for good.
main.go also only wired the notifier for the first cookie spec and
ignored the name and URL the transport reported.
The exit now also sends a new AuthRequired control message to the client
(rate-limited per transport, retried on the transport's next report if no
client is connected yet). It travels over whichever carrier still reaches
the peer, e.g. direct while the document carrier is the one that is
stuck. The client surfaces it to the app as an IPC CookiesRequest marked
Remote; the app answers with a CookiesOffer marked Remote, which the
client forwards to the exit as a CookiesOffer naming the transport, and
the exit applies and persists it. The client's own checks stay local.
Local notifications now carry the reporting transport's name and URL.
The check has to be passed from the exit's address; the next commit
gives the app a way to browse through the tunnel for that.
Cookie control messages carried no transport name, and main.go wired a
single callback for the first cookie-carrying spec only ("multi-transport
cookie routing is left for later"), so with several transports cookies
could only ever reach one of them. Cookies from the app over IPC were
also saved under a different store key (domain or transport name) than
the one replayed on startup (the document URL), so they were never
reloaded.
CookiesPayload gains a transport field. The Manager now serves the
cookie subtypes itself: requests are answered by the exit for the named
transport, responses and offers are applied to it, and both they and IPC
offers go through AcceptCookies, which persists under the key registered
with UseCookieStore, the same one replayed on startup. Messages without a
name (older peers) keep meaning the highest-priority cookie transport.
damnurmum