email address validation is a pain, and you can use a surprising variety
of characters in an address.
(At least we're drawing the line at no quoted characters...)
Closes#44https://github.com/mozilla/fxa-email-service/pull/45
r=philbooth
A direct mapping of functionality from the auth server, so the different
notification types are expected on three different queues. Long-term it
makes sense to simplify that down to a single queue, but this way we can
ease the new service in alongside the existing auth server.
As a first cut, the methods on queues::sqs::Queue all block the thread
in this implementation. A subsequent change will transition to futures.
Error types commonly print the most helpful information via the Debug
trait, which can be accessed using the {:?} format specifier. This
change just ensures we propagate that more useful information when
wrapping other error types.
https://github.com/mozilla/fxa-email-service/pull/30
r=rfk
I was missing some tests for BounceSubtype deserialization, which meant
I hadn't realised that the derived implementation of Deserialize was
mapping values to strings rather than numbers. This change fixes that
and adds the corresponding test coverage.
https://github.com/mozilla/fxa-email-service/pull/29
r=rfk
Loads bounce limits from config and then checks email addresses against
those limits before sending the email. If any address violates a limit,
the request will fail with status 429 and email will not be sent.
As it introduces a dependency on the fxa-auth-db-mysql repo, some extra
scripting has been thrown in to make working with node.js easier.
Running `./tdb` will check whether an `fxa-auth-db-mysql` directory
exists and, if not, clone the repo. Then it will check for running db
server processes and, if none are found, run `npm i`, run the db patcher
and start the db server in a background process. Then it finishes by
invoking the existing `./t` script.
This is not ideal because it leaves the node process running in the
background after tests have finished. But I figure it's good enough for
now because it only leaves one of them running, they don't multiply with
subsequent test runs. And you don't have to use the new script of
course, if you already have the db server running in fxa-local-dev, you
can just run `./t` and the tests should pass. The new script is mostly
there for Travis' benefit.
https://github.com/mozilla/fxa-email-service/pull/22
r=rfk,vbudhram
Extracts the inline validation code from the settings module to a
dedicated deserialize module, so that the validation rules can be better
re-used elsewhere.
Uses functions rather than newtype structs, for 2 reasons:
1. There's an issue in the config crate where newtype structs aren't
deserialized. An unmerged PR exists to fix it, but in the meantime
this changeset works round the problem.
2. When using newtype structs, the tests aren't able to create fresh
instances of the Settings struct unless it is flattened to a single
level.
Maybe we can revisit the newtype struct approach down the line when both
of the above are resolved.
https://github.com/mozilla/fxa-email-service/pull/15
r=rfk
Imitates, as closely as possible, the convict-based approach we use in
our node repos. The major difference is that validation here has to
happen in the code, we can't define it in config.
Settings are applied in the following order:
* config/default.json
* config/${NODE_ENV}.json (optional)
* config/local.json (optional, git-ignored)
* environment variables
I opted to re-use $NODE_ENV instead of some rust-specific environment
variable so that our dev setups will work with minimal changes. If that
seems too weird though I can change it.
Uses the `config` crate, which was the convictiest dependency I could
find.
Not wired in to any behaviour, just does some crude validation and then
returns a hard-coded message id. There is some test coverage, but also
some gaps where I haven't figured out how we should do stuff yet:
* The validation code is punishingly verbose. I evauated a couple of
crates to implement validation, `accord` and `validator`, and opted
for `validator`. However they both seem quite simple, for instance
there's no support for nested objects or values packed inside arrays.
This meant we couldn't lean on the nice, readable macro syntax that's
available and have to explitly validate fields using Rocket's FromData
trait instead.
* Rocket has a feature called error catchers, which I couldn't get to
work. These are supposed to let you return custom error data but, no
matter what I tried, it always seemed to return the default error
response for each type (which is an html string). And even if I could
get those to work, I couldn't see a way to propagate rich error
information, e.g. names of invalid parameters, into the catcher
without having to validate all of the parameters a second time inside
the catcher.
* I tried to write a test case that fired unicode at the endpoint and it
failed.
I'm sure the root cause of these problems is just my own lack of
expertise and we'll figure it out eventually. In the meantime, this
seemed like enough to get us started. I'll open issues to cover the
above.
In terms of code structure, I've just lumped most stuff in to the send
module for now. As we add more functionality, I expect the natural
boundaries to reveal themselves. No point agonising over it yet.
Phil Booth
Beatriz Rizental
JR Conlin