Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

fix(ngHref): allow numbers as input #16652

Merged
merged 3 commits into from
Aug 20, 2018

Conversation

Narretz
Copy link
Contributor

@Narretz Narretz commented Aug 1, 2018

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

What is the current behavior? (You can also link to an open issue here)

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change?

Please check if the PR fulfills these requirements

  • The commit message follows our guidelines
  • Fix/Feature: Docs have been added/updated
  • Fix/Feature: Tests have been added; existing tests pass

Other information:

if (normalizedVal !== '' && !normalizedVal.match(regex)) {
return 'unsafe:' + normalizedVal;
}
return uri;
return uri.toString();
Copy link
Member

Choose a reason for hiding this comment

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

For the record, this will allow more types than just number. (This might be a good thing, but it might also lead to unexpected results, instead of a fastfailure.)

If you want to explicitly only allow numbers and strings, you can have an explicit check (as we do in $anchorScroll for example).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, I was also thinking about this. I've added this mainly because it's weird to sanitize a string value but return the original value. For ngHref and other interpolation it's actually not necessary, as the interpolation itself does the string conversion. So maybe we should move the toString to where the value is passed into the sanitize fn?

Copy link
Member

Choose a reason for hiding this comment

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

Sounds reasonable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@petebacondarwin what do you think about this? Should we stringify here or somewhere earlier in the chain? I have a hard time pinpointing where exactly this behavior changed. I guess it happened somewhere here: #16378

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should do the stringificaton inside trustAs() where we call $$sanitizeUri(). E.g. https://github.com/petebacondarwin/angular.js/blob/e541a33ed73ca4135def5d90b1613e070a43baff/src/ng/sce.js#L443

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good to me! I've updated the implementation and added a new test for custom toString(), too for good measure.

if (normalizedVal !== '' && !normalizedVal.match(regex)) {
return 'unsafe:' + normalizedVal;
}
return uri;
return uri.toString();
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should do the stringificaton inside trustAs() where we call $$sanitizeUri(). E.g. https://github.com/petebacondarwin/angular.js/blob/e541a33ed73ca4135def5d90b1613e070a43baff/src/ng/sce.js#L443

Copy link
Contributor

@petebacondarwin petebacondarwin left a comment

Choose a reason for hiding this comment

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

Yep LGTM now

@Narretz Narretz merged commit 837e519 into angular:master Aug 20, 2018
Narretz added a commit that referenced this pull request Aug 20, 2018
Interpolated content in ngHref must be stringified before being passed to $$sanitizeUri by $sce. Before 1.7.x, the sanitization had happened on the already interpolated value inside $compile.

Closes #16652
Fixes #16626
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants