With some recent testing of our Single Page Application, I have noticed that, upon trying different email validations, using wappler's built in email validation will allow non-english characters to be submitted in a form requiring validation.
Wappler will display that it is invalid - with the text box becoming red with a danger symbol. But yet it will not fail the validation when submitting.
The input box is set to email type, with the validation rules being email. As well as a server side validation of email, and a further validation step, also validating the input is a valid email.
I am more than happy to use a regex expression to solve this issue for myself, however I believe this is a bug within the wappler validation. As it can clearly pick up it is invalid on client side, yet still submits and passes checks.
If anybody can share the regex / validation the built in validation uses, but could also please look into the bug and provide some clarity?
<input id="inp_email" name="email" type="email" class="form-control mb-3" data-rule-email="" dmx-bind:placeholder="{{EmailPlaceholder.value}}" required="" minlength="1" data-msg-minlength="Please enter at least 11 characters.">
Yes so the form is linked to a server action, which then creates a POST request to an external API. Which (along with some other stuff), will add the email to our database and create an automatic email with an OTP.
This is also show in the XHR dev tools panel. Showing a server 200, backed up by the database record.
So therefore, my concern for the bug is the client side is displaying it knows it's invalid, yet will proceed with running the server action, passing the validation in the server action, and then still sending the invalid email to our API.
Ok i see what you mean, the input is marked as invalid when a unicode character like è is entered but the actual validation is not triggered, so it doesn't stop the form from submitting.