The validation of the e-mail is not according to the official e-mail format standard. It does capture most used emails, but a lot might still be considered invalid. A full regex e-mail validation is next to unreadable, because of the allowed variation in the way e-mail addresses can be written and the specific constraints on the various parts of the e-mail address.
@@jdude99lolz There are instances where you might need this regex in client-side form. Google has their gmail for business, therefore the email domain is customized. So when a company wishes to let user register, they must use specific domain. Otherwise it will just be denied immediately.
Don't add your own regex to check if the email is valid please! If you set the type of your input to email as in: , the browser will check if the email address is valid. The one you entered, abc@abc, could potentially be a valid email. The best way to check if an email is valid is to simply send it an email and let the user verify it.
Using this RegEx as a password pattern is a horribly bad idea because: 1.: People with languages that don't use the Latin alphabet (e.g. Russian), or don't use it exclusively (e.g. German) can't put characters from their language as a password, and 2.: Users should be allowed to put special characters like !@#$%^*&... into their password to make it harder to brute force. The perfect RegEx would simply be ".{8,}".
don’t a lot of hashing algorithms restrict you to just alphanumeric and some special characters anyways? i’m not sure about that but i’ve heard it’s common.
@@GavHern no. If an implementation requires an alphanumeric string, it’s a really really bad implementation. In general, a hash function should not work on the string or even the characters. It works directly on the bytes of the given input. And because of that, it doesn’t care if the bytes represent a letter, a number or any special character.
@@kdicus i only recall something about this from an old computerphile video, though i cannot perfectly remember what it said… probably should have looked into it before commenting since it seems i forgot what the point was
Please please please don't try to validate email addresses with regular expressions. You will never think of all the corner cases and you will end up getting both a lot of invalid mail addresses and antagonizing those of your users who have slightly unusual mail addresses.You can check the domain name fairly easily in the backend. But if you really want to check an email address you have to send a mail. Also, checking passwords beyond a minimum length is probably not a good idea. "Password1" satisfies the usual rules (at least 8 characters, characters from 3 different classes) but is of course terrible. "ftzrivpznmgmqpqdmldr" doesn't but is much stronger. And aren't 6 Chinese characters probably stronger than 8 Latin characters? It might be useful to check passwords against haveibeen0wned, but you almost certainly should do that in the backend. That said, client-side validation is absolutely useful for data where you control the format or the format is well-known and simple. Also thanks for the tip about using title. I didn't know that.
Well checking the strength of the password is beyond this scope. For some pages the client doesn't want that kind of security and its okay with just asking for a valid password.
@@b_delta9725 Yeah, but what is a "valid" password? Most systems I've worked with over the last decades accept (almost) any string as a password. So technically, any password is a valid password. Any further restriction is an attempt to force the user to choose a "strong" password.
@@peterholzer4481 that's why its good to ask for at least one number, one capital and one symbol. That's easy with regex, but if you want to force the user to create a good password, you need an algorithm in JS.
@@b_delta9725 It isn't good. It doesn't prevent users from choosing trivial passwords and I doubt it even makes the average password significantly harder to guess. All it does is say "see, we have mildly annoying password rules, so we care about security" which makes about as much sense as "it tastes bad, so it must be healthy". If you don't care about how strong the passwords are, forget any policy and let the user choose whatever they want. If you do care, such simple rules won't help you. That's just security theater.
@@peterholzer4481 For once, it does, you can use any page and test a password with and without symbols and capitals and it's harder to decipher, and with how little effort it takes to put a regex, it's a lot better than just letting them put the letter "a" as their password and move on. But if it's really concerning then drop the regex and use a password api to make sure that if it doesn't take at least a trillion years for a computer to decipher, then the user cannot use it.
If you use `minleng="8"` attribute instead of `{8,}` in pattern browser tips will be somthing like: "Please enter at least 8 characters. (You have now entered 5 characters)"
Nice video ! You might not want to allow a space for after the @ sign in your class, and also mention that if you want a hyphen in the class, it should be escaped or put at the end :)
The browser's constraint validation api is the right tool to use in any sort of client side form validation. That should be preferred over any sort of hack. Or JOI is a really cool library which makes it a tonne more enjoyable 😊
@@big-jo89 Unfortunately yes. In Perl or Python you could include the flags using (?:) syntax (like "(?i:[a-z]+)", but JavaScript or HTML doesn't support that. But you can match on Unicode properties like \p{Letter}.
I just watched formik + yup for form validation and management.....and now watching this. My thoughts: This is all good for vanilla stack, but for frameworks and libs like react, it better to use packages as error handling is a bit hard to manage.
“Hello@hello” is a valid email according to the RFC. I believe it’s because emails could be used internally where an email server might route that happily.
Ah this explains a lot. I was wondering if otherwise the best situation would be for the default validate were to be "fixed", but I guess that is a moot point then.
For email validation I might point out that less is better. When you get overly specific you’ll eventually run into a mismatch issue on a valid address. Best to make your validation be simple like (something before the @)+@+(something after the @).(something after the dot) People that want to put fake emails will, but you don’t want to accidentally throw errors for edge cases that are valid. Best to make validation as minimal as possible and if a real address is critical… use a secondary confirmation method like “an email has been sent, click the link to confirm”
" a mismatch issue on a valid address" ... yes especially if a person doesn't read the RFC and doesn't test against valid addresses. I'm not sure that I like testing for dot in the domain is good. It is perfectly valid for dns-sales@design to be a perfectly valid email address. It is rare(well unknown to me) for top level domain to have an A or MX record, but conforms to standards. /([^@"\s]+|".+")@[^@\s]+/ should be very good at not rejecting email addresses too soon. ([A-Za-z0-9.!#$%&'*+-/=?^_`{|}~]+|".+")@([A-Za-z0-9.!#$%&'*+-/=?^_`{|}~]+|\[[^@[\]\s]+\]) narrows things down but also shouldn't reject anything valid. Likely best to make client-side validation good enough to catch honest mistakes while very possibly not being a full-validator. For security reasons you need to be redoing as much and more validation on the server side. On the server side, you can more fully parse and validate the email. You can test that domain has an A or MX record, try sending a test email, etc. Before sending the test email, the address should be tested enough to make sure that it shouldn't cause any security issues. datatracker.ietf.org/doc/html/rfc2822 datatracker.ietf.org/doc/html/rfc5322
The dot and something after the dot is wrong because emails don't need that. Email validation is very complex so either do it right (by using a solution that follows the official rules) or don't use any validation at all.
@John Ryder Well considering Kevin himself wasn't building his email validation fully strict, and the video was more about hints.... your statement is false. I've been dealing with emails and data validation for over 20 years.
@@izybit my statement didn't mention a dot and then another dot, it mentioned the @ and then a dot. The minimum format would be something like (username)@(domainName).(extension)
Your email regular expression is also bad, not just your password one (as mentioned in my other comment). Seriously, I do like your channel (even though I already know most stuff), but you shouldn't give tips about things that you don't know much about. Your email regular expression doesn't match subdomains as well as top-level domain extensions consisting of multiple parts. For example, in the UK a two-part domain extension is common. Your regular expression only matches domains containing a single period. Another example: Students from the university of Salzburg get email addresses a four-part domain with three periods. You should definitely allow domains with any number of periods in them. Also, you don't include domain extensions containing hyphens in it, which are necessary for Punycode domain extensions that are used in some languages containing non-Latin-alphabet characters. And if you really want to be precise, you actually should allow domains that don't contain a single period at all (which is the default in browsers), because many companies have a domain set up in their local network that doesn't have a domain extension at all. Google for example uses the "go" domain in their company's network. No domain extension at all here. Some of these companies also use email addresses for internal-use only that use these domains, and an employee should be able to put their company internal email address in there, even though the email is not reachable from outside the company's network. But if you, for example, make a service that companies can self-host in their internal network, putting email addresses with domains not ending in a domain extension actually makes sense.
Yes, exactly. I would not bother validating an email address (login) field on the client side. Either the entered value matches a user record or it doesn't, don't try to be too smart. There is an oldish book about Regexes where the author tries to come up with a valid regex that matches all formally valid mail addresses and it's a page long.
@@KelseyThornton Yes, but what I'm saying is that if Kevin makes these tutorial videos, people will use these regular expressions for themselves. I think Kevin has enough reach that he has a responsibility of not giving developers bad-practice tips.
This was really awesome by the way. Thanks for uploading such amazing work. I also would like to thank to all your patrion members. Lots of love and respect from Afghanistan.
The best validation for an email in a form is to send an email and have them validate it. Avoid making valid emails not accepted by overly checking validity.
I just made it this type of video😆 what a coincidence! Anyway these attributes are so powerful 💯 even some senior developer doesn't know about that 😋😆 Love your content as always✌
Interesting... But what would happen if a user hits f12 and remove pattern attr in html and then fill out the inputs and hit the enter key? It can be hack like this? Cuz users can modify html from browser but they cant modify javascript! Let me know what would happen in this case 😁
Doing it in JavaScript offers no extra security, anyone can easily inspect, alter and replay any http requests through the browser builtin devtools bypassing al client side validation. You must validate all user input server side, client side validation is ONLY for improved user experience, not actual validation.
hello . i have been wanting to improve my CSS by taking your classes . but I don't know where to start from . i would like to take your CSS class from the beginners to the advanced .do you have any links that could let me to subscribe to your classes and take the classes . i have learnt CSS before but would like to listen to your full classes And see what I can get from there . please leave a link to those classes and I will go subscribe . Thank you
I'm a weird one in that I actually like regex, but the main thing I learnt from this that I didn't know is using the title to add to the default validation tooltip!
This is gonna be my standart. Thanks a lot for this video, i wanted a way to learn regex but i search about form validation. 2 in 1 ! You're a boss ! :D
Hey, can you make a video about figure and figcaption tags? I saw them on Tailwind CSS site and I think they are great for making semantic cards. Do you think they're worth to use?
thanks for the tips.... we can skip the JS validation now... i have read somewhere that some people can override this client side validations? ... so they suggested to use server side validation too.... is that correct? .... i am exited to see if can customise more this validation like if i want to change the color of input when it not valid...
Client side validation is ONLY for improved user experience, it adds 0 security. Anyone can open up the browser developer tools, go to the network tab, copy a request and alter it any way they want. Your backend will have no way of distinguishing the altered request from one’s coming from normal website use. This is extremely trivial to do and request little knowledge. This is why you must validate on server side, you can never trust client input.
Hi Kevin, keep in mind that validating froms by doing it only in HTML is tricky, because someone who has program experience can just go inspect the browser and remove the required from the html code and then they can login without filling in anything
Client side validation is ONLY ever for improved user experience, it adds 0 security wether you do it in html or in js. The reason for this is that anyone can just open the network tab in browser dev tools, copy any request from there and just alter the values to anything they want. Only server side validation offers any form of security / protection from malicious users.
Great content as always!! I was literally working on regex yesterday at work and I was figuring out how to set a proper one for address. This video gave me great tips of how do it!
You might omit the uppercase characters in the charset and add the "i" modifier (case insensitive) as the RFC has the email address and a hostname being case insensitive.
It's really great to learn from you! BUT Do you really use all of these stuff you teach in your projects? Since most of them are not supported for modern browsers OR supported only in the latest ones. And form validation via HTML is really weak spot! Someone understanding the markup can easly change it and send a broken data to database!
@@VahanBio No. Someone who wants to attack your web server will just talk to it directly and completely bypass any JavaScript you might have. Client side validation is a convenience for the user, it doesn't protect your server at all.
@@VahanBio Client side validation offers no security, it can be easily completely bypassed, an attacker will inspect requests through the browser devtools network tab and copy them to something like postman to alter any way they want. It’s not possible for your server to know the difference, all client side validation is completely bypassed this way. Similarly most security related headers such as cors are only there to protect your users, and do nothing to protect your server. An attacker can easily spoof their origin to bypass cors, it’s the browser that does those checks to protect the client.
If you add the attributes *oninput="this.setCustomValidity('')"* and *oninvalid="this.setCustomValidity('A custom message goes here')* , you can get rid of the default messaging.
Probably best to search online for a more complete and proper regex pattern for these things. If you're just a front end developer, you're probably not aware of all the edge cases or how to handle them, so it's better to go with something tried and tested vs. trying to come up with it on your own. For example, the space before the dash in Kevin's pattern means that it would allow a space in the email address itself, which wouldn't work in the real world. And as for domains, this might catch something like ".design" but it would fail to capture something super-common like ".co.uk".
@@lookupverazhou8599 Well, it would be the same as the overall list of possible DSN domains, you could have any of the Top-Level Domains ( en.wikipedia.org/wiki/List_of_Internet_top-level_domains ) plus the Second-Level Domains ( en.wikipedia.org/wiki/Second-level_domain ). Included in these are domains that don't use the Latin alphabet, which complicates regex even more.
I know a lot of people have mentioned the issue with email validation, but I also wanted to raise one that doesn't seem to have been brought up, ".co.uk". here in the UK we're a country of about 70 million people, and this regex would invalidate all of those because it only accepts 1 dot atm. That's a lot of possible false flags on it's own and I think is sizeable enough to hardly be called an edgecase.
You'll still want to use some proper validation on your forms, but for these client-side hints we can make big improvements with a little extra HTML.
was literally wanting to make a better form validation from the client side not only from backend thanks a lot :D
my first thought with the email validation was "what about '.co.uk'"
thanks a lot man
The validation of the e-mail is not according to the official e-mail format standard. It does capture most used emails, but a lot might still be considered invalid. A full regex e-mail validation is next to unreadable, because of the allowed variation in the way e-mail addresses can be written and the specific constraints on the various parts of the e-mail address.
I've heard good email validation should just be sending an email and seeing if they get it lol
@@jdude99lolz There are instances where you might need this regex in client-side form. Google has their gmail for business, therefore the email domain is customized. So when a company wishes to let user register, they must use specific domain. Otherwise it will just be denied immediately.
In addition in case of longer addresses eg. 20 characters regex is very slow and has to compare like milions of options
Correct. And this is why you should never use the technique shown above to validate email until you know exactly what you are doing.
Don't add your own regex to check if the email is valid please! If you set the type of your input to email as in: , the browser will check if the email address is valid. The one you entered, abc@abc, could potentially be a valid email. The best way to check if an email is valid is to simply send it an email and let the user verify it.
Using this RegEx as a password pattern is a horribly bad idea because: 1.: People with languages that don't use the Latin alphabet (e.g. Russian), or don't use it exclusively (e.g. German) can't put characters from their language as a password, and 2.: Users should be allowed to put special characters like !@#$%^*&... into their password to make it harder to brute force. The perfect RegEx would simply be ".{8,}".
don’t a lot of hashing algorithms restrict you to just alphanumeric and some special characters anyways? i’m not sure about that but i’ve heard it’s common.
@@GavHern no. If an implementation requires an alphanumeric string, it’s a really really bad implementation.
In general, a hash function should not work on the string or even the characters. It works directly on the bytes of the given input. And because of that, it doesn’t care if the bytes represent a letter, a number or any special character.
nice try, but this isn't a russisn channel
@@GavHern I do lots security work, hashing, and I can’t think of a single hashing algorithm that has limitation on special characters.
@@kdicus i only recall something about this from an old computerphile video, though i cannot perfectly remember what it said… probably should have looked into it before commenting since it seems i forgot what the point was
Please please please don't try to validate email addresses with regular expressions. You will never think of all the corner cases and you will end up getting both a lot of invalid mail addresses and antagonizing those of your users who have slightly unusual mail addresses.You can check the domain name fairly easily in the backend. But if you really want to check an email address you have to send a mail.
Also, checking passwords beyond a minimum length is probably not a good idea. "Password1" satisfies the usual rules (at least 8 characters, characters from 3 different classes) but is of course terrible. "ftzrivpznmgmqpqdmldr" doesn't but is much stronger. And aren't 6 Chinese characters probably stronger than 8 Latin characters? It might be useful to check passwords against haveibeen0wned, but you almost certainly should do that in the backend.
That said, client-side validation is absolutely useful for data where you control the format or the format is well-known and simple.
Also thanks for the tip about using title. I didn't know that.
Well checking the strength of the password is beyond this scope. For some pages the client doesn't want that kind of security and its okay with just asking for a valid password.
@@b_delta9725 Yeah, but what is a "valid" password? Most systems I've worked with over the last decades accept (almost) any string as a password. So technically, any password is a valid password. Any further restriction is an attempt to force the user to choose a "strong" password.
@@peterholzer4481 that's why its good to ask for at least one number, one capital and one symbol. That's easy with regex, but if you want to force the user to create a good password, you need an algorithm in JS.
@@b_delta9725 It isn't good. It doesn't prevent users from choosing trivial passwords and I doubt it even makes the average password significantly harder to guess. All it does is say "see, we have mildly annoying password rules, so we care about security" which makes about as much sense as "it tastes bad, so it must be healthy". If you don't care about how strong the passwords are, forget any policy and let the user choose whatever they want. If you do care, such simple rules won't help you. That's just security theater.
@@peterholzer4481 For once, it does, you can use any page and test a password with and without symbols and capitals and it's harder to decipher, and with how little effort it takes to put a regex, it's a lot better than just letting them put the letter "a" as their password and move on.
But if it's really concerning then drop the regex and use a password api to make sure that if it doesn't take at least a trillion years for a computer to decipher, then the user cannot use it.
If you use `minleng="8"` attribute instead of `{8,}` in pattern browser tips will be somthing like: "Please enter at least 8 characters. (You have now entered 5 characters)"
This!
It's best to use the native attributes for what they're capable of, and only rely on the regex pattern for the last bit.
Brutal info omg
Wow, great info!!!
Regex can be tricky but it's sooo powerful, it's a skill you need to have as a backend developer for sure 😉
Every programmer that puts a maximum length on a password should be fired immediately
It's good to put a maximum length otherwise you could crash their server or database but at least set the maximum length to 100
Is there a way to change the style of error tooltips with css?
I came here hoping to learn how to style the error tooltip. Disappointed
PS: I love your channel for HTML nad CSS
Nice video !
You might not want to allow a space for after the @ sign in your class, and also mention that if you want a hyphen in the class, it should be escaped or put at the end :)
Thanks, Yami… Could you show us an example, please? ☺
The browser's constraint validation api is the right tool to use in any sort of client side form validation. That should be preferred over any sort of hack. Or JOI is a really cool library which makes it a tonne more enjoyable 😊
Kevin, if you add the "i" flag after the regex (/[a-z]/gi) it will be case-insensitive. Also you can use \d for digits :)
if you used " / [ ... ] / ig " inside the pattern attribute it won't work!
@@big-jo89 oh, now I understand your comment. So those flags won't work in HTML? Thanks
@@GonzaloMassa
Yeah, exactly
@@big-jo89 Unfortunately yes. In Perl or Python you could include the flags using (?:) syntax (like "(?i:[a-z]+)", but JavaScript or HTML doesn't support that. But you can match on Unicode properties like \p{Letter}.
@@peterholzer4481
Js does support regex fully though, I mean if you used regex inside script it will work just fine
I just watched formik + yup for form validation and management.....and now watching this.
My thoughts: This is all good for vanilla stack, but for frameworks and libs like react, it better to use packages as error handling is a bit hard to manage.
It would be great if you made a video on making a clean 404 page?
BROOO THANK YOU!!!!!!!!!!!!!!!!! YOU'R THE BEST!!!!!! I LEARNED EVERYTNice tutorialNG I NEEDED TO KNOW THAN YOU VERY
“Hello@hello” is a valid email according to the RFC. I believe it’s because emails could be used internally where an email server might route that happily.
Ah this explains a lot. I was wondering if otherwise the best situation would be for the default validate were to be "fixed", but I guess that is a moot point then.
For email validation I might point out that less is better. When you get overly specific you’ll eventually run into a mismatch issue on a valid address. Best to make your validation be simple like (something before the @)+@+(something after the @).(something after the dot)
People that want to put fake emails will, but you don’t want to accidentally throw errors for edge cases that are valid.
Best to make validation as minimal as possible and if a real address is critical… use a secondary confirmation method like “an email has been sent, click the link to confirm”
" a mismatch issue on a valid address" ... yes especially if a person doesn't read the RFC and doesn't test against valid addresses.
I'm not sure that I like testing for dot in the domain is good. It is perfectly valid for dns-sales@design to be a perfectly valid email address. It is rare(well unknown to me) for top level domain to have an A or MX record, but conforms to standards.
/([^@"\s]+|".+")@[^@\s]+/ should be very good at not rejecting email addresses too soon.
([A-Za-z0-9.!#$%&'*+-/=?^_`{|}~]+|".+")@([A-Za-z0-9.!#$%&'*+-/=?^_`{|}~]+|\[[^@[\]\s]+\]) narrows things down but also shouldn't reject anything valid.
Likely best to make client-side validation good enough to catch honest mistakes while very possibly not being a full-validator. For security reasons you need to be redoing as much and more validation on the server side. On the server side, you can more fully parse and validate the email. You can test that domain has an A or MX record, try sending a test email, etc. Before sending the test email, the address should be tested enough to make sure that it shouldn't cause any security issues.
datatracker.ietf.org/doc/html/rfc2822
datatracker.ietf.org/doc/html/rfc5322
The dot and something after the dot is wrong because emails don't need that. Email validation is very complex so either do it right (by using a solution that follows the official rules) or don't use any validation at all.
@John Ryder Well considering Kevin himself wasn't building his email validation fully strict, and the video was more about hints.... your statement is false. I've been dealing with emails and data validation for over 20 years.
@@izybit my statement didn't mention a dot and then another dot, it mentioned the @ and then a dot. The minimum format would be something like (username)@(domainName).(extension)
Your email regular expression is also bad, not just your password one (as mentioned in my other comment). Seriously, I do like your channel (even though I already know most stuff), but you shouldn't give tips about things that you don't know much about. Your email regular expression doesn't match subdomains as well as top-level domain extensions consisting of multiple parts. For example, in the UK a two-part domain extension is common. Your regular expression only matches domains containing a single period. Another example: Students from the university of Salzburg get email addresses a four-part domain with three periods. You should definitely allow domains with any number of periods in them. Also, you don't include domain extensions containing hyphens in it, which are necessary for Punycode domain extensions that are used in some languages containing non-Latin-alphabet characters. And if you really want to be precise, you actually should allow domains that don't contain a single period at all (which is the default in browsers), because many companies have a domain set up in their local network that doesn't have a domain extension at all. Google for example uses the "go" domain in their company's network. No domain extension at all here. Some of these companies also use email addresses for internal-use only that use these domains, and an employee should be able to put their company internal email address in there, even though the email is not reachable from outside the company's network. But if you, for example, make a service that companies can self-host in their internal network, putting email addresses with domains not ending in a domain extension actually makes sense.
Yes, exactly. I would not bother validating an email address (login) field on the client side. Either the entered value matches a user record or it doesn't, don't try to be too smart. There is an oldish book about Regexes where the author tries to come up with a valid regex that matches all formally valid mail addresses and it's a page long.
What does he say @11:01 ?...
@@KelseyThornton Yes, but what I'm saying is that if Kevin makes these tutorial videos, people will use these regular expressions for themselves. I think Kevin has enough reach that he has a responsibility of not giving developers bad-practice tips.
Re email regex: "it's not that complicated" oh boy, do you have a lot to learn...
This was really awesome by the way. Thanks for uploading such amazing work.
I also would like to thank to all your patrion members.
Lots of love and respect from Afghanistan.
After @ there shouldb be also dot allowed for subdomains. A-z and others can be replaced with w for words.
Validating email just doesn't feel worth it at all with all the weird stuff you can have in addresses like Chinese characters and quote marks
You can also set a custom validation message with setCustomValidity - developer.mozilla.org/en-US/docs/Web/API/HTMLObjectElement/setCustomValidity
9:00 nooooo, now you'll except URLs with spaces in them. Which is not a valid URL
I have a stupid question, will this work on PHP? I'm kinda learning how to make a login system for my website.
What about domains that have 2 extensions i.e -
.co.kr
This should be done server side also, doing it in HTML alone is pointless
I think the name of the video doesn't imply otherwise, plus my pinned comment, both say the same thing 🙂
The best validation for an email in a form is to send an email and have them validate it. Avoid making valid emails not accepted by overly checking validity.
This email regex is only valid for latin alphabet emails. I wonder if other alphabets are accepted for email adresses user names.
i stopped wasting time on regex since most patterns are readily available in stackoverflow
i just tried the same in GPT chat, and its working, so no need the regexr tool LOL
I beg you not to do this!
Please let me log into your site as "...."@[2603:c020:800b:fe:23ce:871b:9a09:4eb0] like god intended!
Do you need to use regexr to add the pattern? Can't you just type the pattern in your HTML page?
Why not to use "type='email'" instead of regexp?
Kevin, is there a chance to customize the default error tooltip by css?
@John Ryder will try, thx
This is a good video, but don't use Regex for Email
Men, why is there no standard function for email validation?
i tried to used preventdefault function and it overided the html validation how can i go arround this the method is post
If you allow a space in the domaine name of the email, it will accept a domain with a space, wich is not allowed
How to do that split screen where you can see what you're coding in real time?
Big letters should be banned in email to teach people how to write it right.
This should not be done for security reasons.
I just made it this type of video😆 what a coincidence!
Anyway these attributes are so powerful 💯 even some senior developer doesn't know about that 😋😆
Love your content as always✌
till is not working in safari as it is in chrome
Where I'm coming from - i18n is a must. I don't see any options to resolve this do this html way :) Allright - I've got your point. "Do it on BE side"
Großartig, vielen Dank!
Hi! I love your videos Thank you for sharing your knowledge. Can you make a video of how to include a captcha on a contact form please.
Interesting...
But what would happen if a user hits f12 and remove pattern attr in html and then fill out the inputs and hit the enter key?
It can be hack like this?
Cuz users can modify html from browser but they cant modify javascript!
Let me know what would happen in this case 😁
Doing it in JavaScript offers no extra security, anyone can easily inspect, alter and replay any http requests through the browser builtin devtools bypassing al client side validation. You must validate all user input server side, client side validation is ONLY for improved user experience, not actual validation.
@@d.sherman8563 right. thanks!
If I didn't know regular expressions before, I would definitely be scared by your explanation 🙂 But the video is great, thanks.
thank you so much dude you're a god
Regexp is black magic
hello . i have been wanting to improve my CSS by taking your classes . but I don't know where to start from . i would like to take your CSS class from the beginners to the advanced .do you have any links that could let me to subscribe to your classes and take the classes . i have learnt CSS before but would like to listen to your full classes And see what I can get from there . please leave a link to those classes and I will go subscribe . Thank you
Good video Kevin, I was just looking for something basic and you delivered. Good intro video to regx.
... Tips for validation protection from spammers would be great.
Can we style that tooltip?
I'm a weird one in that I actually like regex, but the main thing I learnt from this that I didn't know is using the title to add to the default validation tooltip!
Hi, Kevin! Can you also take a look at `:invalid` CSS selector in upcoming videos? Thanks
In the 2nd lockdown
I don't think spaces are allowed in domain names, so I'm not sure why a space was added to regex. Good ideas on form.
Man, how old are you
Thank you for this great video, bro you are awesome keep doing this wonderful content and blessings
.
🥰
This is gonna be my standart. Thanks a lot for this video, i wanted a way to learn regex but i search about form validation. 2 in 1 ! You're a boss ! :D
Maybe from now I will be able to type regex for email validation by myself...
This pattern property is verry nice !! Tkx!!
Amazing!!!!
Hey, can you make a video about figure and figcaption tags? I saw them on Tailwind CSS site and I think they are great for making semantic cards. Do you think they're worth to use?
thanks
Cool - I was wondering about whree the validation came from in the short earlier this week.
How would we go on styling those pre-styled browser vendor tooltip ?
Finally somebody that explain regex easily
What would be a recommendation to show * as required for labels?
This is cool but very very very not safe to use in a website
Cool thing is you can still use regex pattern on inputs that don't natively support it, like textarea, with just a little javascript.
What are the requirements to become an expert in creating PayPal Money Adder programs
ikr!
thanks for the tips.... we can skip the JS validation now... i have read somewhere that some people can override this client side validations? ... so they suggested to use server side validation too.... is that correct? .... i am exited to see if can customise more this validation like if i want to change the color of input when it not valid...
Client side validation is ONLY for improved user experience, it adds 0 security. Anyone can open up the browser developer tools, go to the network tab, copy a request and alter it any way they want. Your backend will have no way of distinguishing the altered request from one’s coming from normal website use. This is extremely trivial to do and request little knowledge.
This is why you must validate on server side, you can never trust client input.
Thank you for form content sir
Your voice and presentation is soo soothing
Hi Kevin, keep in mind that validating froms by doing it only in HTML is tricky, because someone who has program experience can just go inspect the browser and remove the required from the html code and then they can login without filling in anything
Client side validation is ONLY ever for improved user experience, it adds 0 security wether you do it in html or in js. The reason for this is that anyone can just open the network tab in browser dev tools, copy any request from there and just alter the values to anything they want.
Only server side validation offers any form of security / protection from malicious users.
Super helpful! Thanks
man this is sooo good 🔥🔥🔥
❤️🔥
Thanks kevin !
Great content as always!! I was literally working on regex yesterday at work and I was figuring out how to set a proper one for address. This video gave me great tips of how do it!
Please note that there are a lot of real usable emails that don't fit this regex.
Be part of the solution, not the problem.
Don't worry, not even gets it right
You might omit the uppercase characters in the charset and add the "i" modifier (case insensitive) as the RFC has the email address and a hostname being case insensitive.
It's really great to learn from you! BUT Do you really use all of these stuff you teach in your projects?
Since most of them are not supported for modern browsers OR supported only in the latest ones.
And form validation via HTML is really weak spot! Someone understanding the markup can easly change it and send a broken data to database!
You can’t do anything about the last part client-side. You always need to validate your inputs server-side as well.
@@TheMaxCacao well true, but I suppose JS is much safer for client side validation then html
@@VahanBio No. Someone who wants to attack your web server will just talk to it directly and completely bypass any JavaScript you might have. Client side validation is a convenience for the user, it doesn't protect your server at all.
@@VahanBio Client side validation offers no security, it can be easily completely bypassed, an attacker will inspect requests through the browser devtools network tab and copy them to something like postman to alter any way they want. It’s not possible for your server to know the difference, all client side validation is completely bypassed this way.
Similarly most security related headers such as cors are only there to protect your users, and do nothing to protect your server. An attacker can easily spoof their origin to bypass cors, it’s the browser that does those checks to protect the client.
SECOND!
If you add the attributes *oninput="this.setCustomValidity('')"* and *oninvalid="this.setCustomValidity('A custom message goes here')* , you can get rid of the default messaging.
For anyone else struggling with regex, I recommend Engineering Man's "Regex - enough to be dangerous"
Probably best to search online for a more complete and proper regex pattern for these things. If you're just a front end developer, you're probably not aware of all the edge cases or how to handle them, so it's better to go with something tried and tested vs. trying to come up with it on your own.
For example, the space before the dash in Kevin's pattern means that it would allow a space in the email address itself, which wouldn't work in the real world. And as for domains, this might catch something like ".design" but it would fail to capture something super-common like ".co.uk".
The tried and tested method is to set the type of your input to "email" and trust the browsers to validate it, no need to add your own pattern, simply
what are all the possible email domains?
@@lookupverazhou8599 Well, it would be the same as the overall list of possible DSN domains, you could have any of the Top-Level Domains ( en.wikipedia.org/wiki/List_of_Internet_top-level_domains ) plus the Second-Level Domains ( en.wikipedia.org/wiki/Second-level_domain ). Included in these are domains that don't use the Latin alphabet, which complicates regex even more.
I know a lot of people have mentioned the issue with email validation, but I also wanted to raise one that doesn't seem to have been brought up, ".co.uk". here in the UK we're a country of about 70 million people, and this regex would invalidate all of those because it only accepts 1 dot atm. That's a lot of possible false flags on it's own and I think is sizeable enough to hardly be called an edgecase.
Since he didn't use the $ to specify the end of the email, I think should still work (i.e. it would match up to .co)