Respect idAttribute when generating signatures.

[tkalmar]

Fixes #33
small fix to respect user provided idAttribute when generating id's

Summary by CodeRabbit

• New Features
  • Added support for customizable Id attribute names in XML signing operations, allowing users to specify a custom attribute name instead of using the default identifier.

[tkalmar]

Not sure if this needs enhancements to provide support for namespaced id's but then the whole idAttribute has to be changed. But in the long run this can then make the idMode parameter obsolete ...

[cjbarth]

@tkalmar , can you add a test showing how this behavior is currently broken?

[coderabbitai]

Walkthrough

The pull request enables customizable ID attribute naming in the SignedXml API by replacing the hardcoded "Id" attribute with the configurable idAttributes[0] value when auto-generating element IDs during signing operations.

Changes

Cohort / File(s)	Summary
Core Implementation src/signed-xml.ts	Modified ensureHasId method to use the first entry of the idAttributes array instead of hardcoded "Id" when generating element ID attributes
Test Suite test/signature-unit-tests.spec.ts	Extended SignedXml constructor options to accept optional idAttribute parameter; added new test case to verify ID generation with custom attribute names and updated XPath queries to use the configured attribute name

Sequence Diagram

N/A

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

• Focused, single-point change in the core ID generation logic using existing array values
• Test additions follow straightforward verification patterns
• No complex control flow or multi-file logic interdependencies introduced

Possibly related PRs

• Fix Id attribute handling in addAllReferences #521: Refactors addAllReferences to use ensureHasId for ID management, creating a direct dependency on the ID-generation logic modified in this PR

Suggested labels

bug

Poem

🐰 A configurable attribute found its way,
No more hardcoded "Id" here to stay,
Now "ID" or "Id" as you see fit,
The rabbit hops through, adjusting each bit! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The pull request title "Respect idAttribute when generating signatures" directly and clearly describes the main change in the changeset. The modifications center on using the user-provided idAttribute option instead of a hardcoded "Id" value when generating IDs during signature computation, which is exactly what the title conveys. The title is concise, specific, and would allow a teammate scanning the commit history to immediately understand the primary objective of this change.
Linked Issues Check	✅ Passed	The code changes directly fulfill the requirements stated in linked issue #33. The modifications replace the hardcoded "Id" attribute with this.idAttributes[0] in the ensureHasId function, allowing the SignedXml constructor to accept an idAttribute option that controls which attribute name is used when generating signatures. Tests have been added to verify that custom idAttribute values are properly respected during signature generation, and the implementation enables callers to control whether "Id", "ID", or other attribute names are output when calling computeSignature(). All primary coding requirements from the linked issue have been implemented.
Out of Scope Changes Check	✅ Passed	The changes in this pull request are tightly focused on the objective defined in linked issue #33. The modifications to src/signed-xml.ts implement the core functionality of respecting idAttribute when generating signatures, the constructor changes add the necessary public API support, and the test updates verify the new behavior. No unrelated changes or functionality beyond the stated scope of respecting the user-provided idAttribute option are present in the changeset.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

src/signed-xml.ts (1)

1332-1332: Consider validating the idAttribute value in the constructor.

The change correctly uses this.idAttributes[0] to respect custom ID attributes. However, there's no validation when a custom idAttribute is provided in the constructor (lines 155-157). Invalid values (empty string, whitespace, invalid XML name characters) could cause issues during signing.

Consider adding validation in the constructor:

     if (idAttribute) {
+      if (typeof idAttribute !== 'string' || !idAttribute.trim()) {
+        throw new Error('idAttribute must be a non-empty string');
+      }
       this.idAttributes.unshift(idAttribute);
     }

test/signature-unit-tests.spec.ts (1)

88-88: Fix TypeScript formatting.

Type annotations should have spaces around the colon and type union operator.

Apply this diff:

-    function verifyAddsId(mode, nsMode, idAttribute:string|undefined = undefined) {
+    function verifyAddsId(mode, nsMode, idAttribute: string | undefined = undefined) {

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 73db72d and 26d9b91.

📒 Files selected for processing (2)

• src/signed-xml.ts (1 hunks)
• test/signature-unit-tests.spec.ts (2 hunks)

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

Learnt from: shunkica
PR: node-saml/xml-crypto#506
File: src/signed-xml.ts:1159-1159
Timestamp: 2025-10-22T21:03:38.354Z
Learning: In node-saml/xml-crypto PR #506, the maintainer (shunkica) requested an issue to separate the overloaded Reference interface into distinct SigningReference and ValidationReference types. Initial hypothesis: signing-only (xpath, isEmptyUri, id, type), validation-only (uri, digestValue, validationError, signedReference), shared (transforms, digestAlgorithm, inclusiveNamespacesPrefixList). This should be proposed and designed in a follow-up, not altered in the current PR.

📚 Learning: 2025-10-22T21:50:05.454Z

Learnt from: shunkica
PR: node-saml/xml-crypto#0
File: :0-0
Timestamp: 2025-10-22T21:50:05.454Z
Learning: In src/signed-xml.ts Line 1099, createReferences mutates ref.uri = id during signing. Maintain this behavior for now; remove/refactor in a separate PR as previously requested by the maintainer.

Applied to files:

• test/signature-unit-tests.spec.ts
• src/signed-xml.ts

🧬 Code graph analysis (1)

test/signature-unit-tests.spec.ts (1)

src/signed-xml.ts (1)

• SignedXml (30-1422)

🔇 Additional comments (1)

test/signature-unit-tests.spec.ts (1)

125-127: Good test coverage for custom ID attributes.

The new test case effectively verifies that custom idAttribute values are respected during signing, using 'myIdAttribute' to ensure the generated IDs use the configured attribute name instead of the default 'Id'.

[cjbarth]

The code looks OK @tkalmar , but I'm not sure what the use-case is. What is the problem that is solved by writing a different attribute for ID other than the traditional Id? We already liberally accept several different attributes for ID, and I'd imagine other libraries do the same.

[tkalmar]

@cjbarth we are working with an customer endpoint which validates our signed xml, at the moment we have to replace Id in the signed xml with xml:id to make the customer system happy. This is somewhat perf killing as we have large xmls and loading them to replace only three id's is not helping, so with this patch we can generate the signed xml with xml:id already and it works without replacing stuff.

[cjbarth]

So, you don't want a different ID, you want a namespace. Do you have a sample XML that you could share? A proper fix would probably be to read the namespace from the existing XML and use that.

[shunkica]

The proper solution would be to make idAttribute/idAttributes of type string | {prefix: string, localName: string, namespaceURI: string}