You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An example - I would like to create a rule in my model, that would check whether my password field contains both numeric and alphabetic characters (also non-english characters) both in front-end and back-end.
So, I create a rule for the 'password' field, where it would be required to match the following pattern - /^(?=.*\p{L})(?=.*[0-9]).+$/u (notice the u at the end, which is the PCRE_UTF8 modifier (see here http://php.net/manual/en/reference.pcre.pattern.modifiers.php )
It looks ahead for utf-8 letters (the (?=.*\p{L}) part) and for numbers (?=.*[0-9]), passes if has at least one of both.
What is the expected result?
In this case I expect, that both in front-end and back-end the validation would pass if password had both letters and numbers and fail if it didn't.
What do you get instead?
Back-end validation is successful, upon sending a correct form data is refreshed and the error is not shown.
However in front-end it fails by showing that the entered password is incorrect, although the password has both numbers and letters.
Additional info
The reason why this happens is that the pattern goes through RegularExpressionValidator when it is being 'compiled' and the 'getClientOptions' method is being called.
In the first line of the method the pattern is being escaped by this function - \yii\helpers\BaseHtml::escapeJsRegularExpression, where in the last lines of the function it is checked, whether there is or is not any flag provided.
The only valid flags are i, g and m, all the other ones are being escaped, therefore if I have a regular expression like previously mentioned, it ends up losing the u flag at the end.
Maybe it would be possible to add the u to the excluded list, so it could be used if necessary? Or perhaps there are reasons why it is excluded in the first place? (I understand that upon releasing 2.0.6 version with the exclusions there could have been some reasons for excluding the u tag as the ES6 was already released one month prior and some broswers still may be incompatible, but this would be a very neat thing to have for patterns)
Q
A
Yii version
2.0.13
PHP version
7.2
Operating system
Ubuntu 16.04
The text was updated successfully, but these errors were encountered:
What steps will reproduce the problem?
An example - I would like to create a rule in my model, that would check whether my password field contains both numeric and alphabetic characters (also non-english characters) both in front-end and back-end.
So, I create a rule for the 'password' field, where it would be required to match the following pattern -
/^(?=.*\p{L})(?=.*[0-9]).+$/u
(notice theu
at the end, which is the PCRE_UTF8 modifier (see here http://php.net/manual/en/reference.pcre.pattern.modifiers.php )It looks ahead for utf-8 letters (the
(?=.*\p{L})
part) and for numbers(?=.*[0-9])
, passes if has at least one of both.What is the expected result?
In this case I expect, that both in front-end and back-end the validation would pass if password had both letters and numbers and fail if it didn't.
What do you get instead?
Back-end validation is successful, upon sending a correct form data is refreshed and the error is not shown.
However in front-end it fails by showing that the entered password is incorrect, although the password has both numbers and letters.
Additional info
The reason why this happens is that the pattern goes through RegularExpressionValidator when it is being 'compiled' and the 'getClientOptions' method is being called.
In the first line of the method the pattern is being escaped by this function -
\yii\helpers\BaseHtml::escapeJsRegularExpression
, where in the last lines of the function it is checked, whether there is or is not any flag provided.The only valid flags are i, g and m, all the other ones are being escaped, therefore if I have a regular expression like previously mentioned, it ends up losing the
u
flag at the end.Maybe it would be possible to add the
u
to the excluded list, so it could be used if necessary? Or perhaps there are reasons why it is excluded in the first place? (I understand that upon releasing 2.0.6 version with the exclusions there could have been some reasons for excluding the u tag as the ES6 was already released one month prior and some broswers still may be incompatible, but this would be a very neat thing to have for patterns)The text was updated successfully, but these errors were encountered: