Research
Security News
Malicious npm Package Targets Solana Developers and Hijacks Funds
A malicious npm package targets Solana developers, rerouting funds in 2% of transactions to a hardcoded address.
An email validator for Rails 3+.
Supports RFC-2822-compliant and RFC-5321-compliant email validation using RFC-3696 validation.
Formerly found at: https://github.com/balexand/email_validator
The default validation provided by this gem (the :loose
configuration option)
is extremely loose. It just checks that there's an @
with something before and
after it without any whitespace. See this article by David Gilbertson
for an explanation of why.
We understand that many use cases require an increased level of validation. This
is supported by using the :strict
validation mode. Additionally, the :rfc
RFC-compliant mode will consider technically valid emails address as valid which
may not be wanted, such as the valid user
or user@somehost
addresses. These
would be valid in :rfc
mode but not valid in :loose
or :strict
.
Add to your Gemfile:
gem 'email_validator'
Run:
bundle install
Add the following to your model:
validates :my_email_attribute, email: true
You may wish to allow domains without a FQDN, like user@somehost
. While this
is technically a valid address, it is uncommon to consider such address valid.
We will consider them valid by default with the :loose
checking. Disallowed
by setting require_fqdn: true
or by enabling :strict
checking:
validates :my_email_attribute, email: {mode: :strict, require_fqdn: true}
You can also limit to a single domain (e.g: you have separate User
and
AdminUser
models and want to ensure that AdminUser
emails are on a specific
domain):
validates :my_email_attribute, email: {domain: 'example.com'}
Default configuration can be overridden by setting options in config/initializers/email_validator.rb
:
if defined?(EmailValidator)
# To completely override the defaults
EmailValidator.default_options = {
allow_nil: false,
domain: nil,
require_fqdn: nil,
mode: :loose
}
# or just a few options
EmailValidator.default_options.merge!({ domain: 'mydomain.com' })
end
This it the default validation mode of this gem. It is intentionally extremely
loose (see the Validation Philosophy section above. It
just checks that there's an @
with something before and after it without any
whitespace.
Enabling :strict
checking will check for a "normal" email format that would
be expected in most common everyday usage. Strict mode basically checks for a
properly sized and formatted mailbox label, a single "@" symbol, and a properly
sized and formatted FQDN. Enabling :strict
mode will also enable :require_fqdn
configuration option.
Strict mode can be enabled globally by requiring email_validator/strict
in
your Gemfile
, by setting the option in config/initializers/email_validator.rb
,
or by specifying the option in a specific validates
call.
Gemfile
:
gem 'email_validator', require: 'email_validator/strict'
config/initializers/email_validator.rb
:
if defined?(EmailValidator)
EmailValidator.default_options[:mode] = :strict
end
validates
call:
validates :my_email_attribute, email: {mode: :strict}
In order to have RFC-compliant validation (according to http://www.remote.org/jochen/mail/info/chars.html),
enable :rfc
mode.
You can do this globally by requiring email_validator/rfc
in your Gemfile
,
by setting the options in config/initializers/email_validator.rb
, or you can do
this in a specific validates
call.
Gemfile
:
gem 'email_validator', require: 'email_validator/rfc'
config/initializers/email_validator.rb
:
if defined?(EmailValidator)
EmailValidator.default_options[:mode] = :rfc
end
validates
call:
validates :my_email_attribute, email: {mode: :rfc}
If you need to validate an email outside a model, you can get the regexp:
EmailValidator.valid?('narf@example.com') # boolean
EmailValidator.valid?('narf@somehost') # boolean false
EmailValidator.invalid?('narf@somehost', require_fqdn: false) # boolean true
NB: Enabling strict mode (mode: :strict
) enables require_fqdn
(require_fqdn: true
), overridding any require_fqdn: false
while
mode: :strict
is set.
EmailValidator.valid?('narf@example.com', domain: 'foo.com') # boolean false
EmailValidator.invalid?('narf@example.com', domain: 'foo.com') # boolean true
EmailValidator.regexp(mode: :strict) # returns the regex
EmailValidator.valid?('narf@example.com', mode: :strict) # boolean
EmailValidator.regexp(mode: :rfc) # returns the regex
EmailValidator.valid?('narf@example.com', mode: :rfc) # boolean
This gem is thread safe, with one caveat: EmailValidator.default_options
must
be configured before use in a multi-threaded environment. If you configure
default_options
in a Rails initializer file, then you're good to go since
initializers are run before worker threads are spawned.
Do you prefer a different email validation gem? If so, open an issue with a brief explanation of how it differs from this gem. I'll add a link to it in this README.
email_address
(https://github.com/K-and-R/email_validator/issues/58)email_verifier
(https://github.com/K-and-R/email_validator/issues/65)All thanks is given to Brian Alexander (balexand) for is initial work on this gem.
Currently maintained by:
FAQs
Unknown package
We found that email_validator demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 2 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
A malicious npm package targets Solana developers, rerouting funds in 2% of transactions to a hardcoded address.
Security News
Research
Socket researchers have discovered malicious npm packages targeting crypto developers, stealing credentials and wallet data using spyware delivered through typosquats of popular cryptographic libraries.
Security News
Socket's package search now displays weekly downloads for npm packages, helping developers quickly assess popularity and make more informed decisions.