Skip to content

Site 404 page breaks on nested paths; Pages workflow grants deploy permissions to the build job #72

Open

Description

@ahrazzle

Site 404 page breaks on nested paths; Pages workflow grants deploy permissions to the build job

Two small hardening items for the site, low priority.

site/404.html uses relative links. These include style.css, favicon.svg, index.html and guide.html. GitHub Pages serves the 404 page at whatever path was requested. On a missing nested path such as https://aska-digital.github.io/ion/a/b, those links resolve to /ion/a/style.css and similar. The page renders unstyled, and its "Abstract" and "Guide" links lead to more 404s. Fix: use root-relative links (/ion/style.css), or add <base href="/ion/"> to the 404 page only. The latter breaks local python3 -m http.server -d _site testing of that one page, which site/build.sh mentions.

.github/workflows/pages.yml sets pages: write and id-token: write for the whole workflow. The build job therefore gets them too. That job checks out the repo and runs site/build.sh from the pushed commit. Only deploy needs those two permissions. Fix: workflow-level permissions: contents: read, and pages: write and id-token: write on the deploy job only.

While there: third-party actions in both workflows (astral-sh/setup-uv@v5, actions/*@v4/v5) are pinned by tag rather than commit SHA. The impact is low, because CI runs with a read-only token and no secrets.

Automated posting by agentic team with human oversight.

Implementation draft awaiting independent code review: #108

Activity

  1. ahrazzle commented on Oct 21, 2026

    @ahrazzle
    ContributorAuthor

    Status after the 2026-10-21 pass: the 404 half is fixed in PR #74. The workflow half is prepared but not pushed, for an environment reason.

    The token available in the environment that prepared this work lacks the workflow scope. GitHub refuses the push of any branch that touches .github/workflows/pages.yml: "refusing to allow an OAuth App to create or update workflow .github/workflows/pages.yml without workflow scope". The SSH route is not registered for this repo either.

    The change itself is small and ready. Whoever works with a workflow-scoped token (the branch behind #62 edited ci.yml, so that route exists) can apply it directly:

     permissions:
       contents: read
    -  pages: write
    -  id-token: write

    and, on the deploy job only:

       deploy:
         needs: build
         runs-on: ubuntu-latest
    +    permissions:
    +      pages: write
    +      id-token: write

    A test that pins both halves is ready to go with it:

    def test_pages_workflow_scopes_deploy_permissions_to_the_deploy_job():
        wf = yaml.safe_load((ROOT / ".github" / "workflows" / "pages.yml").read_text())
        assert wf["permissions"] == {"contents": "read"}
        assert wf["jobs"]["deploy"]["permissions"] == {"pages": "write", "id-token": "write"}
        assert "permissions" not in wf["jobs"]["build"]

    Until that lands, this issue stays open for the workflow half only.

    Automated posting by agentic team with human oversight.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions