群晖 DSM 的网页终端仍然无法使用.

[catsxp]

抽空我下载扩展 测试一下看具体是什么原因导致的！

[YamatoRyou]

抽空我下载扩展 测试一下看具体是什么原因导致的！

群晖的网页终端是目前已知的唯一能重现故障的场合, 我的建议是最好用 VMware 安装一个 DSM (版本: 6.2.3, 机型: DS3615xs) 方便测试.
参考教程: https://post.smzdm.com/p/ar0v4orw/

网页终端是 Docker 套件的一部分, 也就是说进入 DSM 之后还要在套件中心安装 Docker, 在 Docker 中拉取一个镜像, 再从镜像启动容器. 容器的详情窗口出现 "终端机" 才是终端的最终所在位置.

本来我打算直接给你开一个账号省得你折腾, 但随后发现群晖的 Docker 只有在管理组的账号才能使用. 为了避免威胁到系统安全, 这个选项被放弃.

[catsxp]

EditThisCookie 在猫眼开启，功能能否正常，比如获取网页的cookie一类的，只要不执行异常功能的情况下

[YamatoRyou]

EditThisCookie 在猫眼开启，功能能否正常，比如获取网页的cookie一类的，只要不执行异常功能的情况下

打开如图所示的测试页后直接点击扩展图标可以读取 Cookie.
测试期间该扩展本身也没有遇到过异常.

{F0F68468-C484-FED3-3C37-D4C15D50541B}.png (116.87 KiB) 查看 213100 次

[catsxp]

在 StartupParm.txt 添加 --no-sandbox 后再启动 (此时也安装了 EditThisCookie), 问题依旧.
和上面一样, 不安装或禁用这些扩展 (但保持 --no-sandbox 存在) 就恢复了正常.

这些扩展是自定义cookie？
没听明白，关掉沙箱后，是 EditThisCookie 问题依旧，还是没有任何改变
你也用了cookie相关的油猴脚本？

我重新捋一下:
EditThisCookie 用于修改当前标签页所在站点的 cookie, 是一个独立扩展.
它是昨天提到 3 个扩展的其中之一.
目前的情况: 上述 3 个扩展, 只要任意一个启用 (且不动这些扩展的任何配置), 就会导致上述故障.

因为只要 1 个扩展就能重现故障, 所以我只选择了 EditThisCookie 作为 trigger.
昨天的测试不带 --no-sandbox, 结果如下:
a) 安装并启用 EditThisCookie (不对其做任何额外设置, 也不用其修改 cookie), 然后访问群晖的 Web UI 并打开网页终端, 结果: 无法使用;
b) 安装但禁用 EditThisCookie (不对其做任何额外设置, 也不用其修改 cookie), 然后访问群晖的 Web UI 并打开网页终端, 结果: 可以使用;
c) 不安装 EditThisCookie, 然后访问群晖的 Web UI 并打开网页终端, 结果: 可以使用;

抓包方面:
a) 触发故障后抓包, 其中一个请求会长时间卡住;
b) 恢复正常后抓包, 没有异常现象.

今天的测试带 --no-sandbox, 结果如下:
a) 安装并启用 EditThisCookie (不对其做任何额外设置, 也不用其修改 cookie), 然后访问群晖的 Web UI 并打开网页终端, 结果: 无法使用;
b) 安装但禁用 EditThisCookie (不对其做任何额外设置, 也不用其修改 cookie), 然后访问群晖的 Web UI 并打开网页终端, 结果: 可以使用;
c) 不安装 EditThisCookie, 然后访问群晖的 Web UI 并打开网页终端, 结果: 可以使用;

抓包方面:
a) 触发故障后抓包, 其中一个请求会长时间卡住;
b) 恢复正常后抓包, 没有异常现象.

也就是说按同样的测试条件, 无论带不带 --no-sandbox 启动, 都不会影响故障的出现.

--------------------------------
启用或禁用 EditThisCookie 后需要重启浏览器才会触发故障或恢复正常.
2 次测试过程中, 其它 2 个扩展都处于禁用或未安装的状态.

beta-16 针对这个BUG 重构全局css实现方式 有空帮测试一下是否正常！

[YamatoRyou]

这些扩展是自定义cookie？
没听明白，关掉沙箱后，是 EditThisCookie 问题依旧，还是没有任何改变
你也用了cookie相关的油猴脚本？

我重新捋一下:
EditThisCookie 用于修改当前标签页所在站点的 cookie, 是一个独立扩展.
它是昨天提到 3 个扩展的其中之一.
目前的情况: 上述 3 个扩展, 只要任意一个启用 (且不动这些扩展的任何配置), 就会导致上述故障.

因为只要 1 个扩展就能重现故障, 所以我只选择了 EditThisCookie 作为 trigger.
昨天的测试不带 --no-sandbox, 结果如下:
a) 安装并启用 EditThisCookie (不对其做任何额外设置, 也不用其修改 cookie), 然后访问群晖的 Web UI 并打开网页终端, 结果: 无法使用;
b) 安装但禁用 EditThisCookie (不对其做任何额外设置, 也不用其修改 cookie), 然后访问群晖的 Web UI 并打开网页终端, 结果: 可以使用;
c) 不安装 EditThisCookie, 然后访问群晖的 Web UI 并打开网页终端, 结果: 可以使用;

抓包方面:
a) 触发故障后抓包, 其中一个请求会长时间卡住;
b) 恢复正常后抓包, 没有异常现象.

今天的测试带 --no-sandbox, 结果如下:
a) 安装并启用 EditThisCookie (不对其做任何额外设置, 也不用其修改 cookie), 然后访问群晖的 Web UI 并打开网页终端, 结果: 无法使用;
b) 安装但禁用 EditThisCookie (不对其做任何额外设置, 也不用其修改 cookie), 然后访问群晖的 Web UI 并打开网页终端, 结果: 可以使用;
c) 不安装 EditThisCookie, 然后访问群晖的 Web UI 并打开网页终端, 结果: 可以使用;

抓包方面:
a) 触发故障后抓包, 其中一个请求会长时间卡住;
b) 恢复正常后抓包, 没有异常现象.

也就是说按同样的测试条件, 无论带不带 --no-sandbox 启动, 都不会影响故障的出现.

--------------------------------
启用或禁用 EditThisCookie 后需要重启浏览器才会触发故障或恢复正常.
2 次测试过程中, 其它 2 个扩展都处于禁用或未安装的状态.

beta-16 针对这个BUG 重构全局css实现方式 有空帮测试一下是否正常！

3.1.4 beta 16 (64 位), 测试不带 --no-sandbox, 方法和 #278 描述的相同. 结果如下:
a) 安装并启用 EditThisCookie (不对其做任何额外设置, 也不用其修改 cookie), 然后访问群晖的 Web UI 并打开网页终端, 结果: 无法使用;
b) 安装但禁用 EditThisCookie (不对其做任何额外设置, 也不用其修改 cookie), 然后访问群晖的 Web UI 并打开网页终端, 结果: 可以使用;

其它内容见站内私信.

[catsxp]

我重新捋一下:
EditThisCookie 用于修改当前标签页所在站点的 cookie, 是一个独立扩展.
它是昨天提到 3 个扩展的其中之一.
目前的情况: 上述 3 个扩展, 只要任意一个启用 (且不动这些扩展的任何配置), 就会导致上述故障.

因为只要 1 个扩展就能重现故障, 所以我只选择了 EditThisCookie 作为 trigger.
昨天的测试不带 --no-sandbox, 结果如下:
a) 安装并启用 EditThisCookie (不对其做任何额外设置, 也不用其修改 cookie), 然后访问群晖的 Web UI 并打开网页终端, 结果: 无法使用;
b) 安装但禁用 EditThisCookie (不对其做任何额外设置, 也不用其修改 cookie), 然后访问群晖的 Web UI 并打开网页终端, 结果: 可以使用;
c) 不安装 EditThisCookie, 然后访问群晖的 Web UI 并打开网页终端, 结果: 可以使用;

抓包方面:
a) 触发故障后抓包, 其中一个请求会长时间卡住;
b) 恢复正常后抓包, 没有异常现象.

今天的测试带 --no-sandbox, 结果如下:
a) 安装并启用 EditThisCookie (不对其做任何额外设置, 也不用其修改 cookie), 然后访问群晖的 Web UI 并打开网页终端, 结果: 无法使用;
b) 安装但禁用 EditThisCookie (不对其做任何额外设置, 也不用其修改 cookie), 然后访问群晖的 Web UI 并打开网页终端, 结果: 可以使用;
c) 不安装 EditThisCookie, 然后访问群晖的 Web UI 并打开网页终端, 结果: 可以使用;

抓包方面:
a) 触发故障后抓包, 其中一个请求会长时间卡住;
b) 恢复正常后抓包, 没有异常现象.

也就是说按同样的测试条件, 无论带不带 --no-sandbox 启动, 都不会影响故障的出现.

--------------------------------
启用或禁用 EditThisCookie 后需要重启浏览器才会触发故障或恢复正常.
2 次测试过程中, 其它 2 个扩展都处于禁用或未安装的状态.

beta-16 针对这个BUG 重构全局css实现方式 有空帮测试一下是否正常！

3.1.4 beta 16 (64 位), 测试不带 --no-sandbox, 方法和 #278 描述的相同. 结果如下:
a) 安装并启用 EditThisCookie (不对其做任何额外设置, 也不用其修改 cookie), 然后访问群晖的 Web UI 并打开网页终端, 结果: 无法使用;
b) 安装但禁用 EditThisCookie (不对其做任何额外设置, 也不用其修改 cookie), 然后访问群晖的 Web UI 并打开网页终端, 结果: 可以使用;

其它内容见站内私信.

只动 f2fly 如果有必要，请晚点查看它的状态是否不小心让我破坏了

[catsxp]

我开启了扩展，然后 f2fly 新建一个 sh 正常啊！~
不管是删除还是新增，都是正常的！

F12 entry.cgi 一直在刷 图片上传有限制 ，所以截图我就不截devtool部分了

把帐户回收一下，
然后
f2fly 状态如果让我破坏了，帮忙恢复一下！

[YamatoRyou]

我开启了扩展，然后 f2fly 新建一个 sh 正常啊！~
不管是删除还是新增，都是正常的！

F12 entry.cgi 一直在刷 图片上传有限制 ，所以截图我就不截devtool部分了

把帐户回收一下，
然后
f2fly 状态如果让我破坏了，帮忙恢复一下！

可以多试几个图标.
如果多试几次后仍然正常, 我要考虑让你通过远程桌面连接到我的机器上.

[catsxp]

我开启了扩展，然后 f2fly 新建一个 sh 正常啊！~
不管是删除还是新增，都是正常的！

F12 entry.cgi 一直在刷 图片上传有限制 ，所以截图我就不截devtool部分了

把帐户回收一下，
然后
f2fly 状态如果让我破坏了，帮忙恢复一下！

可以多试几个图标.
如果多试几次后仍然正常, 我要考虑让你通过远程桌面连接到我的机器上.

还多试...其实我懂的不多！！！！
我是怕把你的桌面工作环境破坏了！
有否用了防火 防水 墙一类的软件 ，感觉这个更像是数据包给拦截了