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

fix: Avoid unicode-escaping ampersand in recovery URL query string #1212

Merged
merged 2 commits into from
Apr 8, 2021

Conversation

fenech
Copy link
Contributor

@fenech fenech commented Apr 6, 2021

Related issue

#1188
@aeneasr

Proposed changes

Specify option to output JSON without escaping HTML entities, to keep the & in the query string intact.

Checklist

  • I have read the contributing guidelines.
  • I have read the security policy.
  • I confirm that this pull request does not address a security
    vulnerability. If this pull request addresses a security. vulnerability, I
    confirm that I got green light (please contact
    [email protected]) from the maintainers to push
    the changes.
  • I have added tests that prove my fix is effective or that my feature
    works.
  • I have added or changed the documentation.

Further comments

Tested manually using cURL, but I'm not sure about the best way to add automatic tests for this.

I ran go get github.com/ory/[email protected] go mod tidy, which led to the changes in go.mod and go.sum.

@fenech fenech changed the title bugfix: Avoid unicode-escaping ampersand in recovery URL query string fix: Avoid unicode-escaping ampersand in recovery URL query string Apr 6, 2021
Copy link
Member

@aeneasr aeneasr left a comment

Choose a reason for hiding this comment

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

Awesome, thank you! 🎉 Your contribution makes Ory better :)

@@ -191,7 +191,8 @@ func (s *Strategy) createRecoveryLink(w http.ResponseWriter, r *http.Request, _
url.Values{
"token": {token.Token},
"flow": {req.ID.String()},
}).String()})
}).String()},
herodot.UnescapedHTML)
Copy link
Member

Choose a reason for hiding this comment

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

Could you please add a test for this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As I mentioned in the PR description, I wasn't sure about the best way to do it, do you have any suggestions?

Since "\u0026" == "&" in Go, I'm not sure how we could test it from within checkLink, defined here https:/ory/kratos/blob/master/selfservice/strategy/link/strategy_recovery_test.go#L56.

I guess that the way to do it would involve looking at the raw body of the response, before it is decoded into *admin.CreateRecoveryLinkOK, but I'm not sure how to go about doing that in the current tests.

Copy link
Member

Choose a reason for hiding this comment

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

Hm, it also appears that current tests fail due to this? Basically \u0026 is & in UTF-8 speak so all clients that are capable of decoding UTF8 should know what to do here. What library where you facing issues with here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The original issue was observed using curl on the command line: the link returned was not clickable.

Copy link
Member

Choose a reason for hiding this comment

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

I see, could you try curl ... | jq? I guess curl is returning the raw payload

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, that was what I did to get around it in my script 😄

Copy link
Member

Choose a reason for hiding this comment

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

Ok, unless we find a good solution on how to fix the tests or figure out why they fail in the first place we might have to stick with the UTF8 encoded variant, although I agree that it is a bit counterintuitive

@fenech
Copy link
Contributor Author

fenech commented Apr 7, 2021

@aeneasr the tests are passing now - the issue was that Encode adds a newline to the end of the JSON output.

@aeneasr
Copy link
Member

aeneasr commented Apr 8, 2021

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants