Skip to content

fix: vendor glightbox#165

Closed
ParidelPooya wants to merge 1 commit into
mainfrom
fix/vendor-glightbox
Closed

fix: vendor glightbox#165
ParidelPooya wants to merge 1 commit into
mainfrom
fix/vendor-glightbox

Conversation

@ParidelPooya
Copy link
Copy Markdown

Zensical's theme bundle fetches the GLightbox image-lightbox library and its stylesheet from unpkg.com at runtime, which the site's Content Security Policy on docs.aws.amazon.com forbids. AppSec flagged both the direct CSS load (ExternalCDNForbiddenCheck) and the indirect JS load (ExternalCDNDynamicLoadForbiddenCheck).

Zensical guards the unpkg fetch with
typeof GLightbox === "undefined" || GLightbox instanceof Element
so self-hosting the UMD build — which assigns window.GLightbox on load — short-circuits the check and prevents any network request to unpkg.com. This is the same mechanism already in use for Mermaid.

  • Add scripts/vendor_glightbox.py, which reads version and expected sha256 values from scripts/vendor_glightbox.toml, downloads the pinned glightbox build from cdn.jsdelivr.net, and verifies the sha256. The script supports --check (CI-safe) and --latest modes.
  • Vendor glightbox@3.3.1 into docs/assets/javascripts/glightbox.min.js and docs/assets/stylesheets/glightbox.min.css.
  • Register both files under extra_javascript and extra_css in zensical.toml so the browser loads them same-origin.
  • Extend .gitattributes so docs/assets/stylesheets/** is also treated as binary, keeping PR diffs readable for vendored CSS alongside the existing rule for vendored JavaScript.
  • Add a "Verify vendored GLightbox" step to the docs workflow so drift between the committed files and the pinned sha256 values fails CI.
  • Document the new vendored dependency and its upgrade procedure in CONTRIBUTING.md, next to the existing Mermaid entry.

Zensical's theme bundle fetches the GLightbox image-lightbox library
and its stylesheet from unpkg.com at runtime, which the site's Content
Security Policy on docs.aws.amazon.com forbids. AppSec flagged both the
direct CSS load (ExternalCDNForbiddenCheck) and the indirect JS load
(ExternalCDNDynamicLoadForbiddenCheck).

Zensical guards the unpkg fetch with
  typeof GLightbox === "undefined" || GLightbox instanceof Element
so self-hosting the UMD build — which assigns window.GLightbox on load —
short-circuits the check and prevents any network request to unpkg.com.
This is the same mechanism already in use for Mermaid.

- Add scripts/vendor_glightbox.py, which reads version and expected
  sha256 values from scripts/vendor_glightbox.toml, downloads the
  pinned glightbox build from cdn.jsdelivr.net, and verifies the
  sha256. The script supports --check (CI-safe) and --latest modes.
- Vendor glightbox@3.3.1 into
  docs/assets/javascripts/glightbox.min.js and
  docs/assets/stylesheets/glightbox.min.css.
- Register both files under extra_javascript and extra_css in
  zensical.toml so the browser loads them same-origin.
- Extend .gitattributes so docs/assets/stylesheets/** is also treated
  as binary, keeping PR diffs readable for vendored CSS alongside the
  existing rule for vendored JavaScript.
- Add a "Verify vendored GLightbox" step to the docs workflow so drift
  between the committed files and the pinned sha256 values fails CI.
- Document the new vendored dependency and its upgrade procedure in
  CONTRIBUTING.md, next to the existing Mermaid entry.

Refs V2204778244, V2204779958
@yaythomas
Copy link
Copy Markdown
Contributor

superseded by #166

@yaythomas yaythomas closed this May 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants