Comments (6)
It might be best to have a few different varieties built in, perhaps add an IntranetEmail
expression but leave the current as is. At the time I was initially writing the built-in expressions, I know I researched and tested half a dozen different expressions and settled on this one as the most correct for most general uses. However, I don't remember much about my decision process anymore. I was probably thinking that 9 times out of 10 we don't want domains without TLDs. I might not have considered the use case for "+" at all. I'm definitely open to PRs for additional built-in expressions, or possibly we can adjust Email
to allow the "+" but still require the TLD. Others are welcome to comment their thoughts.
from meteor-simple-schema.
I strongly advise to keep regex-based email validation as permissive as possible. [email protected] is enough. The only way to validate an email address is to send an email.
from meteor-simple-schema.
@steph643 what is your reasoning? The new top-level domains would seem to make pattern matches a little more difficult, though it is still in the best interest of UX to try & detect issues and notify the user.
Also, it isn't like this isn't a solved problem. I'd look to projects like WordPress to see what pattern matching it employs.
@aldeed I would like to see '+' supported if it isn't currently.
from meteor-simple-schema.
There are many discussions about this on the Internet. Google: regex email validation.
From an API provider perspective, I think the safest way (unless you want to spend endless hours in support and debates) is to only check [email protected], then to allow users to provide an alternate algorithm.
from meteor-simple-schema.
My goal really is just to give a simple built-in option for people who want to get up and running quickly. You can, of course, provide any regex you find online or create yourself rather than using the built-in. You can also reset SimpleSchema.RegEx.Email
to any regex you wish. So I don't think the aim is to please everyone.
On the other hand, if a package like this can provide a few different expressions that meet the most common validation needs, then that potentially saves a lot of time for a lot of people who would otherwise have to research and find/write their own.
So I still think it might be best to provide a few different options. Maybe the default should indeed be the most permissive, and then one or two less permissive alternatives can be available. Regarding "[email protected]", one could argue that "anything@anything" (i.e., contains one "@" that is not the first character or the last character) is more accurately the bare minimum because, according to the spec, the domain could be an IP address or "localhost".
from meteor-simple-schema.
Didn't see PR #89 until after responding. I think that PR matches pretty well with what I said. Anyone else have comments on it?
from meteor-simple-schema.
Related Issues (20)
- [solved] custom function validation error HOT 1
- autoValue: calling fields() and siblingFields() yields no results on insert HOT 2
- Overwriting SimpleSchema regEx messages HOT 5
- Error: Invalid definition for inMenu field HOT 1
- Match.Where being instantiated as a class, causes error on Meteor 1.6.1 boot HOT 5
- Make a field conditionally required bug HOT 1
- Explicitly indicate this repo is deprecated HOT 1
- How to define a Custom Validation Error in Autoform >= 6.0 HOT 1
- Removing old field from old users? Ignore schema when using $unset ? HOT 1
- typo in dependencies in version 3.0.0 HOT 1
- 1.6.2 Has removed Deps from Tracker package HOT 4
- Warn / strip global regEx schemas? HOT 1
- the optional: true afFieldInput have the required attribute with it HOT 1
- error in Documentation [max] > {{max}} HOT 1
- "must be an object" error even though typeof() returns Object HOT 3
- $pull not behaving as expected HOT 1
- Move this package to Community Packages to support simpl-schema >=3.x HOT 1
- Update autoValue to accept async function HOT 2
- Typescript error when importing SimpleSchema HOT 6
- Using Collection Hook's direct version breaks defaultValue and autoValue on an insert HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from meteor-simple-schema.