完整 URL 在 assets erb 文件中——>多站点问题

RGJ · 2019 年7 月 30 日 11:53

新的 Workbox 服务工作者实现使用了 UrlHelper.absolute。由于这是一个编译后的资源，它会存储完整的 URL，其中包含多站点环境中主主机的完整主机名。

https://github.com/discourse/discourse/blob/master/app/assets/javascripts/service-worker.js.erb#L3-L6

我认为应该改用 UrlHelper.local_cdn_url。这样也能避免在更改主机名后需要重新编译资源。

Falco · 2019 年7 月 30 日 15:27

我认为普遍共识是：Service Workers 绝不应通过 CDN 提供：

github.com/w3c/ServiceWorker

Is it possible to serve service workers from CDN/remote origin?

opened 01:26AM - 04 Aug 16 UTC

closed 09:28AM - 04 Aug 16 UTC

samertm

Hey all, I want to serve a service worker from a CDN, but I can't figure out ho…w to get that to work. I expected this to work: ``` // The header `Service-Worker-Allowed: www.example.com` is set in the response var swURL = "cdn.example.com/sw.js"; var options = {scope: 'www.example.com'}; navigator.serviceWorker.register(swURL, options); ``` But it throws the following error in Chrome: ``` Uncaught (in promise) DOMException: Failed to register a ServiceWorker: The origin of the provided scriptURL ('https://cdn.example.com/sw.js') does not match the current origin ('https://www.example.com'). ``` With the current wording, it seems like Service-Worker-Allowed allows loading the service worker from a remote origin. > `Service-Worker-Allowed` > Indicates the user agent will override the path restriction, which limits the maximum allowed scope url that the script can control, to the given value. > The value is a URL. If a relative URL is given, it is parsed against the script’s URL. https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#service-worker-allowed However, all of the examples and discussion only use Service-Worker-Allowed with relative URLs. Digging through the Chromium code, I'm pretty sure the error is thrown before the request is made to the url, which means it's made before we can check the header on the sw response: ``` void ServiceWorkerContainer::registerServiceWorkerImpl(/* ... */) { // ... if (!documentOrigin->canRequest(scriptURL)) { RefPtr<SecurityOrigin> scriptOrigin = SecurityOrigin::create(scriptURL); callbacks->onError(WebServiceWorkerError(WebServiceWorkerError::ErrorTypeSecurity, String("Failed to register a ServiceWorker: The origin of the provided scriptURL ('" + scriptOrigin->toString() + "') does not match the current origin ('" + documentOrigin->toString() + "')."))); return; } // ... m_provider->registerServiceWorker(patternURL, scriptURL, callbacks.release()); } ``` https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/serviceworkers/ServiceWorkerContainer.cpp?q=%22does+not+match+the+current+origin%22&sq=package:chromium&dr=C&l=224 You can follow the rabbit hole down 'canRequest', but I'm pretty sure nothing in that function allows you to allow remote scripts dynamically (e.g. with a header). Questions: - Is it possible to serve a service worker from a remote origin through some other means? - The spec is currently ambiguous about remote origins -- it doesn't say they aren't allowed, but it doesn't say they are either. Should Service-Worker-Allowed let you serve from a remote origin? Thanks for your time! BTW, you all have done excellent work with the spec.

哦，你的意思是 importScripts 文件吗？你们是否有一个多站点集群，其中每个站点都有不同的 CDN URL？

RGJ · 2019 年7 月 30 日 16:18

是的，在那个 ERB 文件的第 3 行和第 6 行，使用了 importScripts 和 modulePathPrefix。

但你还没有完全理解我的意思。问题出现在多站点集群中没有 CDN 的情况下。

UrlHelper.absolute 和 UrlHelper.local_cdn_url 都能处理有 CDN 和无 CDN 的情况。

absolute：

无 CDN：https://primarysite.ofmultisitecluster.com/javascripts/workbox/workbox-sw.js 不好——对所有非主站点使用远程源，暴露了主集群的主机名
有 CDN：//cdnurl/javascripts/workbox/workbox-sw.js

local_cdn_url：

无 CDN：/javascripts/workbox/workbox-sw.js 好——相对 URL
有 CDN：//cdnurl/javascripts/workbox/workbox-sw.js

因此，后者才是我们想要的。

Falco · 2019 年7 月 30 日 16:52

问题在于，第 3 行和第 6 行并非关于服务工作线程文件本身。

服务工作线程来自基础域名（因为它不能通过 CDN 提供），但该服务工作线程会在运行时懒加载脚本（在此例中是 Workbox 库文件），而这些文件可以通过 CDN 提供。

因此，问题出在你的多站点集群未配置 CDN，这才暴露了该漏洞；而当设置了 DISCOURSE_CDN 时，该漏洞会被掩盖。我只是想了解一下为什么这不会影响我们。

RGJ · 2019 年7 月 30 日 17:06

你说得对，我已经编辑了我的第二篇帖子来修正我的错误。
问题不在于服务工作者文件本身，而是就在这个服务工作者文件里。

是的，正是在这种情况下 bug 才会暴露出来。

RGJ · 2019 年8 月 1 日 14:55

只是想确认一下——我的诊断是否正确？这是否是一个即将修复的 bug？有什么需要我们提供以协助解决的吗？

Falco · 2019 年8 月 1 日 17:06

是的，这看起来是一个需要修复的 bug。我本周就会处理！

Falco · 2019 年8 月 2 日 19:03

嗯，我刚刚在 Meta 控制台上试了一下：

## 当前实现
[1] pry(main)> UrlHelper.absolute("/javascripts/workbox/workbox-sw.js")
=> "https://d3bpeqsaub0i6y.cloudfront.net/javascripts/workbox/workbox-sw.js"

### 拟议的更改
[2] pry(main)> UrlHelper.local_cdn_url("/javascripts/workbox/workbox-sw.js")
=> "/javascripts/workbox/workbox-sw.js"

在我看来，这两个函数似乎不能互相替换。

RGJ · 2019 年8 月 2 日 19:37

你说得对，local_cdn_url 会将本地 URL 替换为 CDN URL。而且这甚至不是本地 URL，而是一个相对路径。

所以我认为用这些来代替那些 UrlHelper 调用就足够了？

importScripts("<%= (Discourse.asset_host || '') + "/javascripts/workbox/workbox-sw.js" %>");

以及

modulePathPrefix: (Discourse.asset_host || '') + "/javascripts/workbox",

Falco · 2019 年8 月 2 日 19:57

阅读 UrlHelper.absolute 的当前实现：

github.com/discourse/discourse

lib/url_helper.rb

main


      
          def self.is_valid_url?(url)
            uri = URI.parse(url)
          
            return true if uri.is_a?(URI::Generic) && url.starts_with?("/") || url.match?(/\A\#([^#]*)/)

看起来当 CDN 为 nil 时（这正是您的情况），它会通过拼接 Discourse.base_url_no_prefix 和参数来构建 URL。

所以问题在于，Discourse.base_url_no_prefix 在多站点环境中是否总是返回第一个主机？

查看代码

github.com/discourse/discourse

lib/discourse.rb

main


      
              @status = status
              @check_permalinks = check_permalinks
              @original_path = original_path
              @custom_message = custom_message
            end
          end
          
          # When a setting is missing

第 288 行变量名 current_hostname 强烈暗示它已考虑到多站点场景

再看这里：

github.com/discourse/discourse

lib/discourse.rb

main


      
          attr_reader :check_permalinks
          attr_reader :original_path
          attr_reader :custom_message

看起来确实如此。目前看来是个死胡同…

再看看其他地方，这个路由之所以有特殊处理，是因为浏览器非常喜欢频繁访问它，而我们不能将其放到 CDN 上把问题甩给别人。在这样做的时候，我们曾遇到过涉及多站点泄露的 bug，该问题已在一年前由 @sam 修复：

是否存在这样一种可能性：您部署该多站点集群的方式以类似 2018 年初我们遇到的那种“泄露式”缓存方式缓存了这个路由？

RGJ · 2019 年8 月 2 日 20:53

不，问题在于它在预编译资源时这样做，这在多站点环境中会引发问题。
因此，解决方案是永远不要在资源中包含主机名（除非配置了资源 CDN，因为该 CDN 在多站点主机之间始终是共享的）。

RGJ · 2019 年8 月 4 日 18:07

@falco 你看到我在上面两帖中提出的解决方案了吗？

Falco · 2019 年8 月 4 日 19:21

是的，但在我的测试中，如果没有 CDN，它无法覆盖子文件夹😭

我认为我们需要使用：

"#{Discourse.asset_host}#{Discourse.base_prefix}/javascripts/workbox"

RGJ · 2019 年8 月 4 日 20:49

嗯，关于子文件夹这一点说得很好。

但是……Discourse.asset_host 可能是 nil，而我从未听说过 Discourse.base_prefix？

不如这样：

importScripts("<%= (Discourse.asset_host || GlobalSetting.relative_url_root) + "/javascripts/workbox/workbox-sw.js" %>");

modulePathPrefix: "<%= (Discourse.asset_host || GlobalSetting.relative_url_root) + "/javascripts/workbox" %>",

Falco · 2019 年8 月 5 日 19:36

这正是我们在此情况下想要的：

irb(main):001:0> puts "a#{nil}bc"
abc

哦，我指的是 Discourse.base_path。

已提交修复，请查看。

RGJ · 2019 年8 月 5 日 20:15

这对我们的情况看起来不错……谢谢！

不过……为了确保万无一失……我不太确定你们是如何在 CDN 上处理资产并结合子文件夹的。但如果你们使用了 Discourse.asset_host，是否仍然会在资产主机上的所有路径前加上子文件夹路径？因为目前的代码就是这样做的。
如果确实如此，那么你们完全可以忽略这一段：slight_smile

Falco · 2019 年8 月 5 日 20:20

这个子文件夹 + CDN 的组合确实给我们带来了不少麻烦。@featheredtoast 做了一些工作来优化这一流程，我们花费了大量时间确保我们的资源服务代码能够在这些奇怪的存储桶、子文件夹等组合中正常运行。

我认为我们现在已经安全了，但如果需要，我们可以重新打开这个问题。

感谢你的错误报告！

codinghorror · 2019 年8 月 13 日 01:00

此主题已在 7 天后自动关闭。不再允许新回复。

话题		回复	浏览量
Assets not serving from CDN in latest update Support	17	1803	2020 年3 月 8 日
Service-worker redirection 403 Self-hosting	4	1413	2022 年4 月 13 日
Defining DISCOURSE_S3_CDN_URL links to assets in S3 CDN URL Support	43	6400	2020 年4 月 22 日
CDN and multisite Self-hosting hosting	2	776	2018 年1 月 23 日
Discourse Development: Failed to register/update a ServiceWorker Support	7	1268	2018 年6 月 11 日

完整 URL 在 assets erb 文件中——>多站点问题

相关话题