AWS SES implementation

[belmirp]

This PR implements the following:

• Sending email as text or HTML via AWS SES
• Sending activation link upon registering new account
• Preventing users which are not in Active status from logging in
• Resending activation link
• Requesting password reset and sending reset link to the email
• Resetting password

Related: #139

[Saibamen]

Please fix warnings from linters

[caseyswilliams]

Shouldn't these always be numbers?

[belmirp]

No, errorCode is a string, numericErrorCode is a number. Example:

var err = new ErrorResponse()
{
ErrorCode = "ut4masterserver.accountpendingactivation",
ErrorMessage = accountNotActiveException.Message,
MessageVars = Array.Empty<string>(),
NumericErrorCode = 401
};

[caseyswilliams]

Ah, right. The http status code from the fetch api will be a number though, so we should either change the http service to pull numeric error code or change it so that it makes the http error code a string. Otherwise you'll never be able to correctly compare it because typescript will think it has a string when it has a number.

[caseyswilliams]

I see how you're using it now, I will make some changes to it, don't worry about it

[belmirp]

We could use numericErrorCode instead, but then you would have "magic" numbers on the frontend. I think string representation of an error is better for understanding.
And when I say errorCode, I am not referring to the HTTP response code (400 or similar) which is a number.

[caseyswilliams]

Http status codes are hardly magic numbers, they are well defined, and easily enumerated. And we still have that numeric case, when the error response isn't of type ErrorResponse. I will make it accept either case.

[belmirp]

Please fix warnings from linters

@Saibamen Where do you see warnings?

[caseyswilliams]

You don't need to toString and compare to empty string here, just !accountId?.length will work. The query string vars are either string or string[] or null, so a length of 0 is empty string or empty array. This code actually wouldn't work if they were null or undefined, because undefined !== ''

[belmirp]

At first, it was giving me LocationQueryValue as variable type, that is why I had to do toString, but now when I check, destructuring an object to a new variable actually does converting to string.

Example: /Login?activationLinkSent=done
Code:

const { activationLinkSent: qActivationLinkSent } = route.query;

  console.log(
    'activationLinkSent:',
    activationLinkSent,
    qActivationLinkSent,
    qActivationLinkSent?.length
  );

Output: activationLinkSent: RefImpl {__v_isShallow: true, dep: Set(1), __v_isRef: true, _rawValue: false, _value: false} done 4

Example 2: /Login?activationLinkSent=
Output: activationLinkSent: RefImpl {__v_isShallow: true, dep: Set(1), __v_isRef: true, _rawValue: false, _value: false} 0

Example 3: /Login?activationLinkSent
Output: activationLinkSent: RefImpl {__v_isShallow: true, dep: Set(1), __v_isRef: true, _rawValue: false, _value: false} null undefined

I will see what kind of check will cover all cases.

[caseyswilliams]

LocationQueryVariable is a type defined as string | string[] | null

The code I gave you covers all cases.

[caseyswilliams]

You're getting that RefImpl because you're outputting activationLinkSent rather than activationLinkSent.value.

[caseyswilliams]

The check should be !qActivationLinkSent?.length because that is just looking for a falsey value. Undefined is falsey and so is 0.

[caseyswilliams]

But again, don't worry about it, I will fix it in the feature branch, you can merge this and I will pull and fix, it is easier to show you than explain in comments

[caseyswilliams]

Please fix warnings from linters

@Saibamen Where do you see warnings?

There are warnings about non-null assertion. I commented how they can be fixed. The warnings are correct, too, it is asserting not null when it isn't necessarily true.

[caseyswilliams]

This is good to merge to the feature branch, I will fix up the commented areas.