Discource-C
/
discourse
mirror of https://github.com/discourse/discourse.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
discourse/app/helpers/splash_screen_helper.rb

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

24 lines
543 B
Ruby
Raw Normal View History

DEV: Compile splash screen JS with ember-cli before inlining (#18150) This lets us use all our normal JS tooling like prettier, esline and babel on the splash screen JS. At runtime the JS file is read and inlined into the HTML. This commit also switches us to use a CSP hash rather than a nonce for the splash screen.
2022-09-01 04:58:48 -04:00
# frozen_string_literal: true
module SplashScreenHelper
FEATURE: Add experimental option for strict-dynamic CSP (#25664) The strict-dynamic CSP directive is supported in all our target browsers, and makes for a much simpler configuration. Instead of allowlisting paths, we use a per-request nonce to authorize `<script>` tags, and then those scripts are allowed to load additional scripts (or add additional inline scripts) without restriction. This becomes especially useful when admins want to add external scripts like Google Tag Manager, or advertising scripts, which then go on to load a ton of other scripts. All script tags introduced via themes will automatically have the nonce attribute applied, so it should be zero-effort for theme developers. Plugins *may* need some changes if they are inserting their own script tags. This commit introduces a strict-dynamic-based CSP behind an experimental `content_security_policy_strict_dynamic` site setting.
2024-02-16 06:16:54 -05:00
def self.raw_js
DEV: Compile splash screen JS with ember-cli before inlining (#18150) This lets us use all our normal JS tooling like prettier, esline and babel on the splash screen JS. At runtime the JS file is read and inlined into the HTML. This commit also switches us to use a CSP hash rather than a nonce for the splash screen.
2022-09-01 04:58:48 -04:00
if Rails.env.development?
FEATURE: Add experimental option for strict-dynamic CSP (#25664) The strict-dynamic CSP directive is supported in all our target browsers, and makes for a much simpler configuration. Instead of allowlisting paths, we use a per-request nonce to authorize `<script>` tags, and then those scripts are allowed to load additional scripts (or add additional inline scripts) without restriction. This becomes especially useful when admins want to add external scripts like Google Tag Manager, or advertising scripts, which then go on to load a ton of other scripts. All script tags introduced via themes will automatically have the nonce attribute applied, so it should be zero-effort for theme developers. Plugins *may* need some changes if they are inserting their own script tags. This commit introduces a strict-dynamic-based CSP behind an experimental `content_security_policy_strict_dynamic` site setting.
2024-02-16 06:16:54 -05:00
load_js
DEV: Compile splash screen JS with ember-cli before inlining (#18150) This lets us use all our normal JS tooling like prettier, esline and babel on the splash screen JS. At runtime the JS file is read and inlined into the HTML. This commit also switches us to use a CSP hash rather than a nonce for the splash screen.
2022-09-01 04:58:48 -04:00
else
FEATURE: Add experimental option for strict-dynamic CSP (#25664) The strict-dynamic CSP directive is supported in all our target browsers, and makes for a much simpler configuration. Instead of allowlisting paths, we use a per-request nonce to authorize `<script>` tags, and then those scripts are allowed to load additional scripts (or add additional inline scripts) without restriction. This becomes especially useful when admins want to add external scripts like Google Tag Manager, or advertising scripts, which then go on to load a ton of other scripts. All script tags introduced via themes will automatically have the nonce attribute applied, so it should be zero-effort for theme developers. Plugins *may* need some changes if they are inserting their own script tags. This commit introduces a strict-dynamic-based CSP behind an experimental `content_security_policy_strict_dynamic` site setting.
2024-02-16 06:16:54 -05:00
@loaded_js ||= load_js
end.html_safe
DEV: Compile splash screen JS with ember-cli before inlining (#18150) This lets us use all our normal JS tooling like prettier, esline and babel on the splash screen JS. At runtime the JS file is read and inlined into the HTML. This commit also switches us to use a CSP hash rather than a nonce for the splash screen.
2022-09-01 04:58:48 -04:00
end
private
def self.load_js
File.read("#{Rails.root}/app/assets/javascripts/discourse/dist/assets/splash-screen.js").sub(
DEV: Correctly strip sourcemap URL from splash-screen js (#22879) In e1d27400f5d8be345383b52bd118e652724a517e we started running the splash-screen JS through terser, which removed the trailing newline from the `sourceMappingURL` line. Adding a reliable end-to-end test for this isn't possible because our testing environment doesn't use terser.
2023-07-31 11:49:27 -04:00
"//# sourceMappingURL=splash-screen.map",
DEV: Compile splash screen JS with ember-cli before inlining (#18150) This lets us use all our normal JS tooling like prettier, esline and babel on the splash screen JS. At runtime the JS file is read and inlined into the HTML. This commit also switches us to use a CSP hash rather than a nonce for the splash screen.
2022-09-01 04:58:48 -04:00
"",
)
rescue Errno::ENOENT
Rails.logger.error("Unable to load splash screen JS") if Rails.env.production?
"console.log('Unable to load splash screen JS')"
end
end