[pmg-devel] [PATCH pmg-gui] utils: escape `/` in regex for emails

[pmg-devel] [PATCH pmg-gui] utils: escape `/` in regex for emails

[Maximiliano Sandoval]

As it is, it is valid ECMA regex but invalid in many other dialects. We
escape it to make it valid in, say PCRE2.

Note that `/` marks the end of the regex [1], hence

    Some@example@oh\no@

is valid according to this regex if we do not escape `/`.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Character_escape

Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
---
Fun fact: This was detected by xgettext while doing tests extracting
strings for translations.

 js/Utils.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/js/Utils.js b/js/Utils.js
index 7fa154e..8974cb9 100644
--- a/js/Utils.js
+++ b/js/Utils.js
@@ -903,7 +903,7 @@ Ext.define('PMG.Async', {
 Ext.apply(Ext.form.field.VTypes, {
     // matches the pmg-email-address in pmg-api
     PMGMail: function(v) {
-	return (/[^\s\\@]+@[^\s/\\@]+/).test(v);
+	return (/[^\s\\@]+@[^\s\/\\@]+/).test(v);
     },
     PMGMailText: gettext('Example') + ": user@example.com",
 });
-- 
2.39.2

Re: [pmg-devel] [PATCH pmg-gui] utils: escape `/` in regex for emails

[Stoiko Ivanov]

Thomas and I talked shortly off-list - and I remembered that we
(Maximiliano and I) - also talked off-list quite a while ago...
sadly I forgot if we agreed on a v2, or if the issue was more with gettext?

just before this gets forgotten:

On Thu, 30 Nov 2023 13:44:16 +0100
Maximiliano Sandoval <m.sandoval@proxmox.com> wrote:

> As it is, it is valid ECMA regex but invalid in many other dialects. We
> escape it to make it valid in, say PCRE2.
> 
> Note that `/` marks the end of the regex [1], hence
> 
>     Some@example@oh\no@
> 
> is valid according to this regex if we do not escape `/`.
> 
> [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Character_escape
> 
> Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
> ---
> Fun fact: This was detected by xgettext while doing tests extracting
> strings for translations.
> 
>  js/Utils.js | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/js/Utils.js b/js/Utils.js
> index 7fa154e..8974cb9 100644
> --- a/js/Utils.js
> +++ b/js/Utils.js
> @@ -903,7 +903,7 @@ Ext.define('PMG.Async', {
>  Ext.apply(Ext.form.field.VTypes, {
>      // matches the pmg-email-address in pmg-api
>      PMGMail: function(v) {
> -	return (/[^\s\\@]+@[^\s/\\@]+/).test(v);
> +	return (/[^\s\\@]+@[^\s\/\\@]+/).test(v);
as is this fails at eslint

from a quick search at developer.mozilla.org:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Character_class:
```
This means /[/]/ is valid without needing to escape the /.
```

also:
```
These are syntax characters in regexes (/ is the delimiter of a regex literal), so they require escaping unless in a character class.
```
(and '/' is in a character-class)
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Character_escape



>      },
>      PMGMailText: gettext('Example') + ": user@example.com",
>  });

Re: [pmg-devel] [PATCH pmg-gui] utils: escape `/` in regex for emails

[Dominik Csapak]

AFAICS the original issue

On 2/23/24 19:11, Stoiko Ivanov wrote:

>>
>> Note that `/` marks the end of the regex [1], hence
>>
>>      Some@example@oh\no@
>>
>> is valid according to this regex if we do not escape `/`.
>>

is not because of unescaped '/' but because the regex is not anchored
and thus only parts of the input must match... (and that it does)

Re: [pmg-devel] [PATCH pmg-gui] utils: escape `/` in regex for emails

[Thomas Lamprecht]

Am 26/02/2024 um 08:07 schrieb Dominik Csapak:
> On 2/23/24 19:11, Stoiko Ivanov wrote:
> 

FYI: this makes it seem like below was written by Stoiko, but it wasn't,
it's rather part of Maximiliano's original commit message.

>>>
>>> Note that `/` marks the end of the regex [1], hence
>>>
>>>      Some@example@oh\no@
>>>
>>> is valid according to this regex if we do not escape `/`.
>>>
> 
> is not because of unescaped '/' but because the regex is not anchored
> and thus only parts of the input must match... (and that it does)
> 

yeah, that seems indeed to be the issue. @Maximiliano can you please try that
and send a patch for it, if it works out.

And FWIW, the extra parenthesis around the regex could be dropped too (just
a code style improvement though), so