FIX: Create the creator context demo's 51Did through the client script

[jwrosewell]

Problem

The creator context demo page created its 51Did with a call of its own to
the json endpoint. The cloud release now in production issues an
identifier only once the page has run the snippets the service asks for
and sent what they collected, so that call comes back with every
identifier null and a reason in the matching nullreason field.

Asked with a browser User-Agent and the same parameters the page used,
against https://cloud.51degrees.com on 17 September 2026, every one of
the six identifiers came back null, each with a reason of this shape.

idproblicnullreason -> Can not form IdProbLic. The page has not finished
running its snippets, so no 51Did is created on this call. The page still
has to run device.screenpixelsheightjavascript,
device.screenpixelswidthjavascript, device.pixelratiojavascript,
device.javascriptgethighentropyvalues,
device.thirdpartycookiesenabledjavascript and send 51D_ScreenPixelsHeight
and 51D_ScreenPixelsWidth and 51D_PixelRatio and 51D_GetHighEntropyValues
and 51D_ThirdPartyCookiesEnabled with its next request, which the
51Degrees client script does before it reports complete.

The page then read json.fodid.idproblic || json.fodid.idprobglobal,
which is null, and the first row of the demo failed.

There is a second fault on the same page. The verification call is made
from the browser and the service compares this browser's device and
browser against the creator's from the snippet values. Where a browser
needs those values and the request does not carry them, the service does
not give a verdict and says that the page has not sent them yet.

What changed

• pipeline.developer-examples/pipeline.developer-examples.fodid/src/main/resources/fodid/creator-context/page.html
  • The page loads the 51Degrees client script for its resource key,
    carrying id.usage and id.email on the script's own address, and
    takes the identifier from what the script reports through its
    complete function. The service puts both parameters into the
    request the script makes, which was checked against the live service
    by fetching the script with them and reading the evidence it builds,
    where they appear as {"id.usage":"non-marketing","id.email":...}.
  • The script is loaded on both paths, the one that creates and the one
    that checks an identifier pasted in from another browser, because the
    comparison needs this browser's values either way.
  • Every cookie whose name begins 51D_, which is how the client script
    stores what the snippets collected, is sent with the verify-full
    call. Forwarding by prefix rather than by a list means the page does
    not fall behind the script when the set of snippets changes.
  • The page ends with a Find out more section, which it did not have
    before, giving the reader the 51Degrees documentation and a way to
    get in touch, plus the repositories the demo is built from.
• CreatorContextDemoServer.java and the module's README.md say what
  steps one and two now do.
• src/test/resources/fodid/creator-context/creator-context-page-harness.js
  runs the page's script in Node against a small stand in for a browser, with a stand in client script
  that reports six identifiers and writes two 51D_ cookies, and prints
  what the page asked for as one line of JSON. Nothing in it reaches a
  network.
• src/test/java/pipeline/developerexamples/fodid/CreatorContextPageTests.java
  checks that the page loads the client script once with the usage on
  its address, that it makes no
  request of its own for an identifier, that the identifier the script
  reported is the one verified and is made safe for a URL, that the
  snippet values go with the verification and unrelated cookies do not,
  that the sealed result is redeemed on the demo's own server, that the
  page ends with the Find out more section, and that the page's script
  parses under node --check.
• The harness is a test resource, so Maven copies it beside the page in
  the build output and the tests find both on the class path.

Verification

• mvn -pl pipeline.developer-examples/pipeline.developer-examples.fodid test, Maven 3.9.16 with JDK 21 on Windows:
  Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, being the seven
  new page tests and the nine that were already there.
• Fail without, pass with. With page.html put back to the version on
  main and nothing else changed, the seven new tests give
  Tests run: 7, Failures: 6, the one that still passes being the parse
  check, which the old page also passes. One of the failures names the
  call the old page made,
  https://cloud.51degrees.com/api/v4/json?resource=.... Putting the
  fixed page back returns Tests run: 7, Failures: 0.
• Against the live service on 17 September 2026, with a resource key
  entitled to the 51Did properties. The call the old page made returns
  all six identifiers null with the reason above. The same call carrying
  the five snippet values returns all six identifiers.
• The script the service serves for that key was fetched with
  id.usage=non-marketing and id.email=... on its address. It parses
  under node --check, it carries both parameters in the evidence it
  sends, and it leaves an object named fod with a complete function,
  which is what the page reads.
• The link lint for this repository is clean.

Outstanding

• The same shape of creation call is in the demo pages of the other
  language packages, which are handled separately.
• This stays a draft.

The same change in the other ports

The Node port of this change is
pipeline-node#208.

Overlap with other work in this repository

#140 changes the same
demo server. The two were merged locally in both directions and both merges
are clean.

CI on this branch, 17 September 2026

The "Pull Requests" workflow was dispatched on this branch with dryrun=true,
which builds the branch and merges nothing. Run
35186948063
ran on e90b52b, the head of this branch, and concluded success with all 15
jobs green. In the Ubuntu_Java_21 job the Maven totals are 632 tests run, 0
failures, 0 errors and 6 skipped, with no error lines in the log.

This branch is three commits behind main and merges into it cleanly.
The nightly checks out the pull request, merges main into it and builds
that before it merges anything, so the combination is tested there.

[jwrosewell]

Proven in CI

Full build and test run on this branch: https://github.com/51Degrees/pipeline-java/actions/runs/35186948063

A draft pull request only runs the link lint, so the Pull Requests workflow was dispatched against this branch as a dry run to get real evidence. Nothing was merged, and the log shows why: with no pull request based on this branch the run builds the branch on its own as pull request 0, and the checkout and completion steps both print "Not running for a PR".

All 15 jobs finished green, being 11 build and test jobs (Java 8, 11, 17 and 21 on Ubuntu and Windows, and Java 11, 17 and 21 on macOS), the pull request lookup, the configure step, the performance comparison and the completion step.

Reading the job logs rather than the conclusions, each job reports 23 Maven module summaries, and on Java 11 and later they add up to 632 tests run with 0 failures, 0 errors and 0 skipped. Java 8 runs 617, the difference being the tests that need a later Java. The log contains no "BUILD FAILURE", no "FAILURES!", no "ERRORS!" and no summary line with a non-zero failure or error count.

The pull request has not been marked ready and no review has been requested.