Vollständige URL in assets-ERB-Datei → Probleme bei Multisite

RGJ · 30. Juli 2019 um 11:53

Die neue Workbox-Service-Worker-Implementierung verwendet UrlHelper.absolute. Da es sich um ein kompiliertes Asset handelt, wird die vollständige URL gespeichert, die den vollständigen Hostnamen des Primärhosts in einer Multi-Site-Umgebung enthält.

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

Ich denke, es sollte stattdessen UrlHelper.local_cdn_url verwendet werden. Dies umgeht zudem die Notwendigkeit, Assets nach einer Änderung des Hostnamens neu zu kompilieren.

Falco · 30. Juli 2019 um 15:27

Ich denke, der allgemeine Konsens ist, dass Service Worker niemals von einem CDN ausgeliefert werden sollten:

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.

Ah, meinst du also die importScripts-Dateien? Hast du einen Multi-Site-Cluster, bei dem jede Site eine eigene CDN-URL hat?

RGJ · 30. Juli 2019 um 16:18

Ja, importScripts und modulePathPrefix in den Zeilen 3 und 6 dieser ERB-Datei.

Aber Sie verstehen mich nicht ganz. Die Probleme treten dort auf, wo in einem Multisite-Cluster kein CDN vorhanden ist.

Sowohl UrlHelper.absolute als auch UrlHelper.local_cdn_url können Situationen mit und ohne CDN handhaben.

absolute:

kein CDN: https://primarysite.ofmultisitecluster.com/javascripts/workbox/workbox-sw.js schlecht – fremde Herkunft für alle Sites außer der Primärsite, wodurch der Hostname des Primärclusters offengelegt wird
CDN: //cdnurl/javascripts/workbox/workbox-sw.js

local_cdn_url:

kein CDN: /javascripts/workbox/workbox-sw.js gut – relative URL
CDN: //cdnurl/javascripts/workbox/workbox-sw.js

Daher ist Letzteres das, was wir wollen.

Falco · 30. Juli 2019 um 16:52

Das Problem ist, dass diese Zeilen (3 und 6) sich nicht auf die Service-Worker-Datei beziehen.

Der Service Worker stammt von der Basisdomain (da er nicht über ein CDN ausgeliefert werden kann), aber dieser Service Worker importiert zur Laufzeit verzögert Skripte (in diesem Fall die Workbox-Bibliotheksdateien), die über ein CDN ausgeliefert werden können.

Das Problem besteht also darin, dass Ihr Multisite-Cluster kein CDN konfiguriert hat, was diesen Fehler offenlegt, der jedoch maskiert ist, wenn DISCOURSE_CDN gesetzt ist. Ich wollte nur wissen, warum uns das nicht betrifft.

RGJ · 30. Juli 2019 um 17:06

Du hast recht, ich habe meinen zweiten Beitrag bearbeitet, um meine Fehler zu korrigieren.
Es geht nicht um die Service-Worker-Datei, sondern sie befindet sich IN der Service-Worker-Datei.

Ja, genau dann wird der Fehler aufgedeckt.

RGJ · 1. August 2019 um 14:55

Nur zur Sicherheit – ist meine Diagnose korrekt und handelt es sich um einen Bug, der behoben wird? Gibt es etwas, das Sie von uns benötigen, um weiterzuhelfen?

Falco · 1. August 2019 um 17:06

Ja, das sieht nach einem Fehler aus, der behoben werden muss. Ich werde diese Woche dafür sorgen!

Falco · 2. August 2019 um 19:03

Hmmm, ich habe es gerade in einer Meta-Konsole ausprobiert:

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

### Vorgeschlagene Änderung
[2] pry(main)> UrlHelper.local_cdn_url("/javascripts/workbox/workbox-sw.js")
=> "/javascripts/workbox/workbox-sw.js"

Das sieht für mich nicht nach austauschbaren Funktionen aus.

RGJ · 2. August 2019 um 19:37

Du hast recht, local_cdn_url ersetzt eine lokale URL durch eine CDN-URL. Und das ist nicht einmal eine lokale URL, sondern eine relative.

Ich denke also, dass dies ausreichen würde, anstatt dieser UrlHelper-Aufrufe?

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

und

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

Falco · 2. August 2019 um 19:57

Beim Lesen der aktuellen Implementierung von 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\#([^#]*)/)

Sieht es so aus, als würde die URL durch Konkatenation von Discourse.base_url_no_prefix mit dem Parameter erstellt, wenn CDN nil ist – was in Ihrem Fall zutrifft.

Das Problem ist also, dass Discourse.base_url_no_prefix in einer Multisite-Umgebung immer die erste Hostadresse zurückgibt?

Ich schaue mir den Code an

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

Der Name der Variablen hier, current_hostname bei Zeile 288, spricht stark dafür, dass sie multisite-fähig ist

Und laut

github.com/discourse/discourse

lib/discourse.rb

main


      
          attr_reader :check_permalinks
          attr_reader :original_path
          attr_reader :custom_message

scheint das auch der Fall zu sein. Bisher also eine Sackgasse…

Ein anderer Blickwinkel: Diese Route hat eine besondere Behandlung erhalten, weil Browser sie extrem häufig abfragen und wir sie nicht auf ein CDN auslagern dürfen, um das Problem weiterzugeben. Dabei hatten wir vor einem Jahr einen Fehler, der mit einem Multisite-Leck zusammenhing, der von @sam behoben wurde:

Gibt es die Möglichkeit, dass die Art und Weise, wie Sie diesen Multisite-Cluster bereitstellen, diese Route auf eine undichte Weise zwischenspeichert, ähnlich wie wir es Anfang 2018 hatten?

RGJ · 2. August 2019 um 20:53

Nein, das Problem besteht darin, dass dies beim Precompiling von Assets geschieht, was in einer Multisite-Umgebung zu Problemen führt.
Die Lösung besteht daher darin, den Hostnamen niemals in die Assets aufzunehmen (außer bei einem Asset-CDN, falls einer eingerichtet ist, da dieser ohnehin immer zwischen den Multisite-Hosts gemeinsam genutzt wird).

RGJ · 4. August 2019 um 18:07

@falco hast du meine vorgeschlagene Lösung zwei Beiträge weiter oben gesehen?

Falco · 4. August 2019 um 19:21

Ja, aber in meinen Tests werden Unterordner ohne CDN nicht abgedeckt

Ich denke, wir müssen Folgendes verwenden:

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

RGJ · 4. August 2019 um 20:49

Hmm, guter Punkt bezüglich des Unterordners.

Aber… Discourse.asset_host kann nil sein, und von Discourse.base_prefix habe ich noch nie gehört?

Wie wäre es damit:

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

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

Falco · 5. August 2019 um 19:36

Genau das wollen wir in diesem Fall:

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

Oh, ich meinte Discourse.base_path.

Ich habe gerade eine Korrektur committet, bitte schau sie dir an.

RGJ · 5. August 2019 um 20:15

Sieht für unseren Fall gut aus … danke!

Aber … nur zur Sicherheit: Ich bin mir nicht sicher, wie ihr Assets auf einem CDN in Kombination mit einem Unterordner handhabt. Wenn ihr Discourse.asset_host verwendet, wird dann auch der Pfad des Unterordners allen Pfaden auf dem Asset-Host vorangestellt? Genau das macht der Code derzeit.

Wenn das tatsächlich so ist, könnt ihr diesen Absatz völlig ignorieren

Falco · 5. August 2019 um 20:20

Dieses ganze Subordner- und CDN-Thema hat uns tatsächlich jede Menge Probleme bereitet. @featheredtoast hat einige Arbeiten zur Straffung durchgeführt, und wir haben viel Zeit damit verbracht, sicherzustellen, dass unser Code für die Bereitstellung von Assets ordnungsgemäß mit diesen seltsamen Kombinationen aus Buckets, Subordnern usw. funktioniert.

Ich glaube, wir sind auf der sicheren Seite , aber falls nötig, können wir das Thema wieder öffnen.

Danke für den Fehlerbericht!

codinghorror · 13. August 2019 um 01:00

Dieses Thema wurde automatisch nach 7 Tagen geschlossen. Neue Antworten sind nicht mehr erlaubt.

Thema		Antworten	Aufrufe
Assets not serving from CDN in latest update Support	17	1833	8. März 2020
Service-worker redirection 403 Self-hosting	4	1417	13. April 2022
Defining DISCOURSE_S3_CDN_URL links to assets in S3 CDN URL Support	43	6454	22. April 2020
CDN and multisite Self-hosting hosting	2	780	23. Januar 2018
Discourse Development: Failed to register/update a ServiceWorker Support	7	1269	11. Juni 2018

Vollständige URL in assets-ERB-Datei → Probleme bei Multisite

Verwandte Themen