Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enforce consistent transform processing #380

Merged
merged 1 commit into from
Aug 24, 2023

Conversation

cjbarth
Copy link
Contributor

@cjbarth cjbarth commented Aug 22, 2023

During a refactor, a bug was introduced that caused inconsistent processing of transforms. This PR fixes this inconsistency and adds a check to make sure that another inconsistency, that of trying to transform a string, isn't introduced. Ideally, the xpath library would throw if a string is passed instead of a Node, which would solve this problem.

This addresses an issue observed by @srd90 in the bottom part of his comment here.

@cjbarth cjbarth added the bug label Aug 22, 2023
const transform = this.findCanonicalizationAlgorithm(transformName);
transformedXml = transform.process(canonXml, options).toString();
if (xpath.isNodeLike(transformedXml)) {
// If, after processing, `transformedNode` is a string, we can't do anymore transforms on it
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it impossible to apply @xmldom/xmldom and xpath again if input for next transform is string (i.e. to select root Node with xpath)? or something like that...I did not browse source codes before writing this question.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually tried that. The problem is detailed in the comment in that function.

If we get a string like <root><child></child></root> and parse it using @xmldom/xmldom, we get <root><child/><root>, which, while having the same meaning, is different, and causes problems for our tests and signatures. The code comment says that this is kind of shortening is incorrect, but I'm not entirely sure why.

Copy link
Collaborator

@LoneRifle LoneRifle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, unblocking

@cjbarth cjbarth merged commit fa2922f into node-saml:master Aug 24, 2023
7 checks passed
@cjbarth cjbarth deleted the transform-processing branch August 24, 2023 02:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants