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

Added: function-url-scheme-blacklist rule. #2626

Merged
merged 5 commits into from
Jun 20, 2017

Conversation

alexander-akait
Copy link
Member

Which issue, if any, is this issue related to?

#2513

Is there anything in the PR that needs further explanation?

No, it's self explanatory.

@alexander-akait
Copy link
Member Author

/cc @stylelint/core

Copy link
Member

@jeddy3 jeddy3 left a comment

Choose a reason for hiding this comment

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

Looking good.

Minor doc request. Additionally, can you update:

  • docs/user-guide/example-config.md.
  • docs/user-guide/rules.md.

If we ever add any more rules which operate on the scheme of a URL I suggest we abstract some of the code this and the whitelist rule, e.g. is schemeless url, into utilities. I think it's fine at the moment, though.

@@ -0,0 +1,67 @@
# function-url-scheme-blacklist

Specify a blacklist of allowed url schemes.
Copy link
Member

Choose a reason for hiding this comment

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

Specify a blacklist of disallowed url schemes.

@alexander-akait
Copy link
Member Author

@jeddy3 stupid error, sorry

@alexander-akait alexander-akait force-pushed the function-url-scheme-blacklist branch from 76e07a7 to 9f7c21f Compare June 12, 2017 17:56
@alexander-akait
Copy link
Member Author

/cc @jeddy3

Copy link
Member

@jeddy3 jeddy3 left a comment

Choose a reason for hiding this comment

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

LGTM thanks

Copy link
Member

@hudochenkov hudochenkov left a comment

Choose a reason for hiding this comment

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

Great work!

I have few questions, though, in comments.

Also, please, make all “url” → “URL” in readme, because “URL” is an acronym.

const ruleName = "function-url-scheme-blacklist"

const messages = ruleMessages(ruleName, {
rejected: scheme => `Unexpected url scheme "${scheme}:"`,
Copy link
Member

Choose a reason for hiding this comment

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

Upper case “URL”.

Copy link
Member Author

Choose a reason for hiding this comment

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

done, also in whitelist rule.

return (root, result) => {
const validOptions = validateOptions(result, ruleName, {
actual: blacklist,
possible: [_.isString],
Copy link
Member

Choose a reason for hiding this comment

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

Readme says it accepts array|string. I'm not sure if it checks that. There're no tests if only one string was in config (not array with one string).

Copy link
Member Author

Choose a reason for hiding this comment

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

@hudochenkov we use this in all *-blacklist/*-whitelist rules.


testRule(rule, {
ruleName,
config: [[]],
Copy link
Member

Choose a reason for hiding this comment

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

Why this test group rejects https and data? Is it an undocumented behaviour?

Copy link
Member Author

@alexander-akait alexander-akait Jun 20, 2017

Choose a reason for hiding this comment

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

@hudochenkov this used if your want add all schemes to blacklist, analogy in whitelist

Copy link
Member

Choose a reason for hiding this comment

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

But still behaviour isn't documented anywhere. We should document this.


testRule(rule, {
ruleName,
config: [""],
Copy link
Member

Choose a reason for hiding this comment

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

Why this test group rejects https and data? Is it an undocumented behaviour?

Copy link
Member Author

Choose a reason for hiding this comment

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

@hudochenkov we already have same tests in function-url-scheme-whitelist

Copy link
Member

Choose a reason for hiding this comment

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

But still behaviour isn't documented anywhere. We should document this.

Copy link
Member Author

Choose a reason for hiding this comment

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

@hudochenkov can your help me with this, I would like the current time to concentrate on the new rules (#2528) and I'm bad at documentation 😞

Copy link
Member

@jeddy3 jeddy3 Jun 20, 2017

Choose a reason for hiding this comment

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

@hudochenkov Good catch! Sorry I missed this. This isn't the correct behaviour. Both [""] and [[]] should allow all schemes.

This is how the other -blacklist rules behave. The -whitelist rules behave differently because whitelists and blacklists are different.

It's useful to think as:

blacklist: [] = "blacklist nothing" i.e. "everything is ok"
whitelist: [] = "whitelist nothing" i.e. "nothing is ok".

@alexander-akait
Copy link
Member Author

/cc @hudochenkov

@alexander-akait alexander-akait force-pushed the function-url-scheme-blacklist branch from 93b5a52 to bae664d Compare June 20, 2017 14:08

testRule(rule, {
ruleName,
config: [""],
Copy link
Member

@jeddy3 jeddy3 Jun 20, 2017

Choose a reason for hiding this comment

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

@hudochenkov Good catch! Sorry I missed this. This isn't the correct behaviour. Both [""] and [[]] should allow all schemes.

This is how the other -blacklist rules behave. The -whitelist rules behave differently because whitelists and blacklists are different.

It's useful to think as:

blacklist: [] = "blacklist nothing" i.e. "everything is ok"
whitelist: [] = "whitelist nothing" i.e. "nothing is ok".

@alexander-akait
Copy link
Member Author

@jeddy3 can your help with documentation this?

@jeddy3
Copy link
Member

jeddy3 commented Jun 20, 2017

@jeddy3 can your help with documentation this?

It's a behaviour issue, not a documentation one. I'm pushing up a commit to fix though.

@jeddy3
Copy link
Member

jeddy3 commented Jun 20, 2017

  • I've added to tests to the property-*list rules to show how the whitelist and blacklist rule behaviours are correctly different when given empty strings or arrays as primary options.
  • This behaviour comes for free when using the matchesStringOrRegExp util. I've updated function-url-scheme-blacklist to use it.
  • Likewise, support for regex also comes for free when using matchesStringOrRegExp.
  • I've removed the tests for case insensitive primary options. None of the other *-*list rules have case-insensitive primary options. If we want to revisit this behaviour, so should do so across the board and in a separate issue.

@alexander-akait
Copy link
Member Author

@jeddy3 After commits what are my actions here? Or just wait when @hudochenkov do review?

@jeddy3
Copy link
Member

jeddy3 commented Jun 20, 2017

Or just wait when @hudochenkov do review?

Just wait on @hudochenkov as my commits came off the back of his original review.

Copy link
Member

@hudochenkov hudochenkov left a comment

Choose a reason for hiding this comment

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

RegEx addition is 🔥

And again about "" and [] configurations. We won't document them?


A [URL scheme](https://url.spec.whatwg.org/#syntax-url-scheme) consists of alphanumeric, `+`, `-`, and `.` characters. It can appear at the start of a URL and is followed by `:`.

This rule treats URL schemes as case insensitive (`https` and `HTTPS` are the same).
Copy link
Member

Choose a reason for hiding this comment

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

I've removed the tests for case insensitive primary options. None of the other *-*list rules have case-insensitive primary options. If we want to revisit this behaviour, so should do so across the board and in a separate issue. — @jeddy3

Is this line in readme still valid?

Copy link
Member

Choose a reason for hiding this comment

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

Yes. I've added tests to show this.

Like all the other *-*list rules, this rule now only accepts lowercase primary options but is case insensitive when checking for matches.

So function-url-scheme-blacklist: "http" will disallow both http://g.co/x.jpg and HTTP://g.co/x.jpg.

#2660 is about allowing the user to specify primary options in any case e.g. function-url-scheme-blacklist: "HTTP", or function-blacklist: "translateX".

@jeddy3
Copy link
Member

jeddy3 commented Jun 20, 2017

And again about "" and [] configurations. We won't document them?

I'm not sure there's any need to do that now because the behaviour is intuitive. We don't document this behaviour in any of the other *-blacklist rules for this reason.

scheme-blacklist: [] = "blacklist nothing" i.e. "all schemes are ok" seems pretty clear to me.

Copy link
Member

@hudochenkov hudochenkov left a comment

Choose a reason for hiding this comment

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

Thank you for your work, @evilebottnawi and @jeddy3!

@jeddy3 jeddy3 merged commit c3b4788 into master Jun 20, 2017
@jeddy3 jeddy3 deleted the function-url-scheme-blacklist branch June 20, 2017 22:41
@jeddy3
Copy link
Member

jeddy3 commented Jun 20, 2017

Changelog

  • Added: function-url-scheme-blacklist rule (#2626).

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

Successfully merging this pull request may close these issues.

3 participants