Skip to content

pg-manual: PKG_URL still points at legacy iHub deployment (main.postguard.ihub.ru.nl) — intentional? #54

Description

@dobby-coder

Observation

pg-manual/examples/utils.js:13 hardcodes:

export const PKG_URL = 'https://main.postguard.ihub.ru.nl/pkg'

This is the legacy Radboud iHub PKG deployment. The other three sub-projects all default to the modern staging hostnames:

  • pg-sveltekit/src/lib/config.ts:5https://pkg.staging.postguard.eu
  • pg-node/src/config.mjs:4https://pkg.staging.postguard.eu
  • pg-dotnet/Program.cs:10https://pkg.staging.postguard.eu

pg-manual has had this URL since it was first added (commit 64582e1, 2026-04-21) and it survived dep-bump PRs #43 and #50. It is the only file in the repo still pointing at the iHub host.

Question

Is the iHub PKG intentional for pg-manual — e.g. the only deployment that still accepts the irma-demo.gemeente.personalData.* schemes the example uses — or is this an oversight that should track the other examples and move to pkg.staging.postguard.eu?

If the latter, this is a one-line change in utils.js plus a re-run of `npm run dev` to verify the Yivi flow still completes against staging.

If the former, a one-line comment in utils.js explaining the discrepancy would prevent the next audit from re-asking.

Files

  • pg-manual/examples/utils.js:13

Flagging for maintainer judgement — not dispatching a worker since the correct value depends on deployment intent.

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionFurther information is requested

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions