-
Notifications
You must be signed in to change notification settings - Fork 474
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
Move XML functions to utility module #571
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note for future: I'd love to get ride of non-null assertions in favor of an actual runtime validation of the data.
I like the idea and recommend dropping "util" from the directory name, leaving it as just "xml". The word "utility" doesn't convey much useful information. It implies minor or miscellaneous functions but I think that's implied by it being an internal library. |
As I look more at what @markstos is saying, it seems we might also be able to consolidate some stuff from |
@cjbarth Yes, true, I did see them then forgot to mention them. I was not 100% sure I should move them, at least one of them (signXmlResponse) seems to be SAML logic to me (it's about a Response element) I think there is actually a nice factorization opportunity with |
(after digging a bit more |
@cjbarth a @markstos Added one commit to move the signXml function to xml module. The change in this commit is slightly more involved than previous commits in this PRs, so review it carefully :) In particular, I probably fixed or broke something, see my comment in the code ;) I have not touched to the function calling signXml yet, I think their destiny could be decided later, in order not to make that PR bigger that it is already ;) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really like where you are going with this, but your last commit on this branch is a step too far and breaks stuff. I'd like to get a test written that catches this. It should be an easy test. If we take "should sign a simple saml request"
and "should place the Signature element after the Issuer element"
and compare the signatures generated with the same settings, they shouldn't be equal.
I improved the existing tests, I don't see any reason to resort to regexp parsing xml if everything is deterministic and we can check the full result. I confirmed the tests failed with the previous version and fixed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. I'll leave this open for a day or so before landing it to let others review.
test/saml-post-signing-tests.spec.ts
Outdated
result.should.match(/<DigestValue>[A-Za-z0-9/+=]+<\/DigestValue>/); | ||
result.should.match(/<SignatureValue>[A-Za-z0-9/+=]+<\/SignatureValue>/); | ||
const doc = await parseXml2JsFromString(result); | ||
doc.should.be.deepEqual({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is certainly more robust than what we had before. I think this is why a lot of tests compare to a static file: this makes the individual test not fit on a single screen. I can't think of a great solution right now, so I'm not looking for a change, but am open to ideas, perhaps in a follow-on PR.
@markstos This looks good to me, but I wanted to leave it open to give you a chance to look in case you're interested. |
@forty If you're OK with it, I'd like to hold off on landing this until #574 lands. We have been trying to get #574 done for a while and I'd like to not complicate the already herculean efforts to split out I still want to work with you and #574 to make sure these both land before we release 3.x in a few weeks if you're up for it. |
Haha, well I cannot say I'm overly enthusiastic to having to tackle that conflict that promises to be huge, but I'll trust you in choosing the order of merge and will do my best to rebase quickly if needed :) |
(and I have to add, I'm one of those that would be more then happy to get rid of the passport dependencies, so i know it's for a good cause :) ) |
@forty We've landed that big PR to start the separation of node-saml from the passport strategy parts. If you would like to revisit your changes here, I'll try to keep up with you in reviewing them. |
It adds better typings and already allowed to catch an incorrect type. It will also make the code safer since the returned type is checked at runtime.
@cjbarth Done for that one too! It was easier than expected 😅 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good as it is, but I notice that there may be a duplicate helper function. See below.
Description
This PR moves most of the XML but non SAML logic to a dedicated file. It tries to improve some types when it's possible.
The idea is:
1- to isolate dependencies, which I think is always a good idea. Especially when those dependencies are non in TS, this allows to group the "typing danger zone"
2- shrink saml.ts by moving as much as possible non SAML related logic out.
This PR should not break anything and is done without updating any tests as a result.
Possible follow ups:
This PR is best reviewed commit per commit.
Let me know what you think.