When building software-as-a-service, many different pre-production environments are often in play. Developers, product managers, and QA engineers work together to test software in various environments, but there’s often confusion around which user accounts can be used in which environments. Often, software environments do not map 1:1 to 3rd party services, making even more confusion.

Mailsac provides disposable email accounts that can be created within a private custom with little or no overhead to keep testing environments separate and prevent user collisions with third party providers.

Common Environment Setup Example

A QA team may have a test environment called “UAT” and developers have a different test environment called “Staging.”

The infrastructure might map to URLs with different subdomains like:

• uat.example.com – QA team
• staging.example.com – Developers
• app.example.com – Production (customers)

where each subdomain has a completely separate database with a users table.

However, our sample app uses a 3rd identity provider (such as Amazon Cognito, Forgerock, Auth0, etc). The identity provider only has two environments:

• test-identity.example.com – All non-production usage (UAT, Staging)
• identity.example.com – Production (customers)

Furthermore, our app uses Stripe, which also has only two environments:

• Stripe Test Mode – All non-production usage (UAT, Staging)
• Production Mode – Production (customers)

One can imagine a users database table with the following properties:

• users.id int, primary
• users.email text, unique
• users.identity_provider_id text, unique, corresponds to the Identity Provider
• users.stripe_customer_id text, unique, corresponds to the Stripe Customer ID

Such a setup is common. Problems begin brewing when using the same email address in multiple environments.

Password issues with shared email addresses

A QA person wants to test their app. They sign up with alice@example.com in UAT. alice@example.com was created by a friendly sysadmin at their company. It is a real email inbox. The company has to pay a few bucks per month for the inbox, and it isn’t easily accessible by anybody else. Where’s that password again? Oh you asked Dave from IT to reset the email password? Oh you mean the UAT app password was changed only? The new password should be in a spreadsheet..oops somebody reset it and didn’t update the password? It doesn’t look like I have access to the alice@example.com inbox. Wait a second..the Dev team is also using it?

Identity Provider Clash, Stripe duplicate

UAT person uses alice@example.com and creates the user account with the Identity Provider, linking the identity_provider_id to their user in UAT. They also link the Stripe customer.

id	email	identity_provider_id	stripe_id
22	alice@example.com	idp_q7e4	cus_t6n

But then a developer in Staging attempts to perform the action but gets blocked by the identity provider, and duplicates the customer in Stripe with the same email address, making the tracking of financial transactions overly complicated. UAT and Stating also end up with a different user id.

id	email	identity_provider_id	stripe_id
19	alice@example.com	NULL (failed)	cus_yb1

It is possible the same password is used for alice@example.com with the identity provider, and both UAT and Development are able to login. But the identity_provider_id will need to be manually set to match both environments, and it will never match the users.id column.

Let’s add one more common layer: role based permissions.

Developer 1 sets up alice@example.com to

These are just a few of the problems with using a limited number of shared credentials for testing software.

Using Mailsac for Test User Accounts

A software team and QA team can share the Mailsac Business account to add nearly unlimited email addresses, and apply special features to up to 50 private address across 5 custom domains (and more via addons). Mailsac allows any custom subdomain of *.msdc.co, it may not even be necessary to involve an IT department to configure DNS.

QA team sets up example-uat.msdc.co.

The QA team will create 10 private addresses with specific purposes such as a user they will configure in uat.example.com with elevated admin permissions:

Next the Dev team, can do something similar but with a different custom domain, and different private email addresses.

Setting up a bunch of private addresses is simple and included with any paid plan. It can help prevent test credential collisions.

Random Inboxes and API Keys

It is not even necessary to setup private addresses, as done above, to receive email.

With a custom domain, any Developer or QA person can send email to any address in the domain without needing to create it first. Then they can check the mail with a personal API key.

The Business Plan allows creating multiple custom API keys:

To make a random address, generate a random string:

openssl rand -hex 4 yields de692e19 (for example)

and prefix it to your custom domain:

de692e19@dev-env-sample.msdc.co

Assume Greg’s API key is: wv6OCCXE4svjxuv7sOsCBA (note: never share these!)

He can easily check the inbox using the following URL scheme:
https://mailsac.com/inbox/de692e19@dev-env-sample.msdc.co?_mailsacKey=wv6OCCXE4svjxuv7sOsCBA

Or get messages as JSON:

curl --header 'Mailsac-Key: wv6OCCXE4svjxuv7sOsCBA' https://mailsac.com/api/de692e19@dev-env-sample.msdc.co/messages

which returns an array of messages including any links to be clicked.

[{
  "_id": "m77238f-0",
  "inbox": "de692e19@dev-env-sample.msdc.co",
  "subject": "Confirm your account or something",
  //.........
  "links": ["https://app.example.com/confirm-account/iOZifOYkLX5qFfEo"]
}]

Concluding remarks

We hope this guide provides an overview of how software teams are using Mailsac to simplify testing.