Add examples to clarify Host and Regular expression URI match behavior #41

gene1wood · 2019-01-31T21:39:30Z

Add an example to the Host section illustrating that Host not only doesn't match parent domains but also doesn't match subdomains
Add an example to Regular expression illustrating that the example regex matches substrings of the URI (because there is no end of string character)

Add an example to the Host section illustrating that Host not only doesn't match parent domains but also doesn't match subdomains Add an example to Regular expression illustrating that the example regex matches substrings of the URI (because there is no end of string character)

kspearrin · 2019-01-31T21:52:35Z

Can we change the regex example to include an end of string character? That was the intent of the example.

gene1wood · 2019-01-31T22:38:48Z

@kspearrin Ah even better, I'd assumed it was just a somewhat confusing set of examples (all of which happen to end in google.com but didn't need to). A typo in the regex makes a lot more sense. I've updated the PR have a look.

Instead of adding an example to the Regular expression section to clarify that the regex shown doesn't require the string end in google.com, let's instead change the regex to end in a `$` and all the existing examples make a lot more sense.

I find it important that examples actually follow best practices. The current regex one is not for two reasons: 1. Not escaping dots in URIs when writing regex is a mistake that is often made, even by advanced regex people. I think this comes from the way we humans look at URIs. Dots are so common in their, aren’t they? Yes, but we write proper regular expressions here, not something in between. 2. `^https://.*google.com$` looks very artificial to me to point out the weaknesses of regular expressions for this use case. I find such an example very good for this purpose but there should also be a "good example" that complements it. Updates: bitwarden#41

I find it important that examples actually follow best practices. The current regex one is not for two reasons: 1. Not escaping dots in URIs when writing regex is a mistake that is often made, even by advanced regex people. I think this comes from the way we humans look at URIs. Dots are so common in their, aren’t they? Yes, but we write proper regular expressions here, not something in between. 2. `^https://.*google\.com$` is an improper regex (as already pointed out because it also matches `malicious-site.com`) that is only there to show the weaknesses of regular expressions for this use case. I find such an example very good for this purpose but there should also be a "good example" that complements it. I found such a "good example" that I hope is more useful and has no unwanted loopholes. Updates: bitwarden#41

I find it important that examples actually follow best practices. The current regex one is not for two reasons: 1. Not escaping dots in URIs when writing regex is a mistake that is often made, even by advanced regex people. I think this comes from the way we humans look at URIs. Dots are so common in there, aren’t they? Yes, but we write proper regular expressions here, not something in between. 2. `^https://.*google\.com$` is an improper regex (as already pointed out because it also matches `malicious-site.com`) that is only there to show the weaknesses of regular expressions for this use case. I find such an example very good for this purpose but there should also be a "good example" that complements it. I found such a "good example" that I hope is more useful and has no unwanted loopholes. Updates: bitwarden#41

gene1wood · 2020-08-14T18:12:39Z

_articles/features/uri-match-detection.md

@@ -75,7 +75,7 @@ The regular expression option allows you to write any simple or complex [regular

 Example:

- URI regex value: `^https://.*google.com`
+- URI regex value: `^https://.*google.com$`


As @ypid points out in #158 The regex as written

^https://.*google.com$

should actually be

^https://.*google\.com$

This is an alternative solution the problem identified in bitwarden#158 that only corrects the regex mistake but doesn't add a good example and a bad example. The original mistake was introduced in d40a73f and then I overlooked it in bitwarden#41.

I find it important that examples actually follow best practices. The current regex one is not for two reasons: 1. Not escaping dots in URIs when writing regex is a mistake that is often made, even by advanced regex people. I think this comes from the way we humans look at URIs. Dots are so common in there, aren’t they? Yes, but we write proper regular expressions here, not something in between. 2. `^https://.*google\.com$` is an improper regex (as already pointed out because it also matches `malicious-site.com`) that is only there to show the weaknesses of regular expressions for this use case. I find such an example very good for this purpose but there should also be a "good example" that complements it. I found such a "good example" that I hope is more useful and has no unwanted loopholes. Updates: bitwarden#41

I find it important that examples actually follow best practices. The current regex one is not for two reasons: 1. Not escaping dots in URIs when writing regex is a mistake that is often made, even by advanced regex people. I think this comes from the way we humans look at URIs. Dots are so common in there, aren’t they? Yes, but we write proper regular expressions here, not something in between. 2. `^https://.*google\.com$` is an improper regex (as already pointed out because it also matches `malicious-site.com`) that is only there to show the weaknesses of regular expressions for this use case. I find such an example very good for this purpose but there should also be a "good example" that complements it. I found such a "good example" that I hope is more useful and has no unwanted loopholes. Updates: bitwarden#41 Replaces: bitwarden#160

I find it important that examples actually follow best practices. The current regex one is not for two reasons: 1. Not escaping dots in URIs when writing regex is a mistake that is often made, even by advanced regex people. I think this comes from the way we humans look at URIs. Dots are so common in there, aren’t they? Yes, but we write proper regular expressions here, not something in between. 2. `^https://.*google\.com$` is an improper regex (as already pointed out because it also matches `malicious-site.com`) that is only there to show the weaknesses of regular expressions for this use case. I find such an example very good for this purpose but there should also be a "good example" that complements it. I found such a "good example" that I hope is more useful and has no unwanted loopholes. Updates: bitwarden#41 Alternative: bitwarden#158 Replaces: bitwarden#160

I find it important that examples actually follow best practices. The current regex does not escaping dots in URIs when writing regex is a mistake that is often made, even by advanced regex people. I think this comes from the way we humans look at URIs. Dots are so common in there, aren’t they? Yes, but we write proper regular expressions here, not something in between. Updates: bitwarden#41 Alternative: bitwarden#158 Replaces: bitwarden#160

I find it important that examples actually follow best practices. The current regex does not escaping dots in URIs when writing regex is a mistake that is often made, even by advanced regex people. I think this comes from the way we humans look at URIs. Dots are so common in there, aren’t they? Yes, but we write proper regular expressions here, not something in between. Updates: #41 Alternative: #158 Replaces: #160

Revert the regex example and change the regex

744f246

Instead of adding an example to the Regular expression section to clarify that the regex shown doesn't require the string end in google.com, let's instead change the regex to end in a `$` and all the existing examples make a lot more sense.

kspearrin merged commit 0ab2dc0 into bitwarden:master Jan 31, 2019

gene1wood deleted the patch-1 branch January 31, 2019 22:50

ypid mentioned this pull request Aug 14, 2020

Add regex example to "Match detection for URIs" that is not broken #158

Merged

gene1wood commented Aug 14, 2020

View reviewed changes

gene1wood mentioned this pull request Aug 14, 2020

Correct mistake in regex example #160

Closed

gene1wood mentioned this pull request Feb 10, 2021

Mistake in regex example in URI detection documentation #392

Closed

ypid mentioned this pull request Feb 10, 2021

Fix URI vault regex example #393

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add examples to clarify Host and Regular expression URI match behavior #41

Add examples to clarify Host and Regular expression URI match behavior #41

gene1wood commented Jan 31, 2019

kspearrin commented Jan 31, 2019 •

edited

gene1wood commented Jan 31, 2019 •

edited

gene1wood Aug 14, 2020

Add examples to clarify Host and Regular expression URI match behavior #41

Add examples to clarify Host and Regular expression URI match behavior #41

Conversation

gene1wood commented Jan 31, 2019

kspearrin commented Jan 31, 2019 • edited

gene1wood commented Jan 31, 2019 • edited

gene1wood Aug 14, 2020

Choose a reason for hiding this comment

kspearrin commented Jan 31, 2019 •

edited

gene1wood commented Jan 31, 2019 •

edited