Email and password authentication, email change flow, email verification, GitHub authentication, and improved UX/UI.
Better authentication for ScreenshotOne dashboard
Email and password authentication, email change flow, email verification, GitHub authentication, and improved UX/UI.
Since ScreenshotOne was launched in 2022, the authentication process hasn’t changed much except for the migration from Go to TypeScript and, as a consequence, using Next.js and NextAuth.js for the dashboard authentication instead of Go and raw HTML with CSS.
The authentication flow just worked, but accumulated a lot of feature requests and UI/UX issues.
I decided to fix most of them at once and share with you the results and the reasoning behind of the decisions.
By the way, you can try the new flow at the dashboard sign-in page. Any feedback is much appreciated, feel free to email support@screenshotone.com
.
NextAuth.js (v4) and its successor Auth.js are great libraries. I had been using NextAuth.js (v4) and it was time to upgrade to Auth.js. While researching all available authentication libraries for Next.js, I discovered Better Auth.
The main reasons why I chose Better Auth and went with it:
I even managed to made a tiny contribution to it:
It was a few lines of code to add it with Better Auth:
That type of authentication was requested by many users. But I didn’t hurry to implement it. I was weighing upsides and downsides of adding it. Plus, NextAuth.js (v4) didn’t support it out of the box.
Today, after seeing email providers having outages, I think it is worth adding it. At least users who already signed up, will be able to sign in the case if emailing is not working.
Once a year, a ScreenshotOne user requests to change their email. I didn’t implement it from the start and often did manually when I received support tickets.
But, luckily, Better Auth has a built-in flow for that:
It took me a few hours to implement, test and deploy the new change email flow.
I made email verification a required step for the new sign-up flow, except if the email was already verified by third-party providers like Google or GitHub.
It might reduce the number of successful sign-ups, especially if due to some reasons verification emails are going to spam.
But I want to make sure that all users have a real verified email address. For an API product like ScreenshotOne it is a must, because if something happens with integrations, billing, or quota limits are reached, users must be notified and able to react.
Otherwise, one of their critical integrations might fail and they will not be able to know about it and react.
In case, if it was a casual SaaS product or not a critical component for businesses, I would consider, not requiring email verification.
Once a verification email is sent, instead of showing a successful “toaster” message:
Now, you will be redirected to a dedicated page:
It will reduce the frustration and support tickets. Since not everyone notice that the email was sent and often request to send it again.
ScreenshotOne is not only, but mostly a product for developers and most of them have a GitHub account. Adding GitHub authentication as an option should simplify the sign-up process.
And indeed, the hypothesis was correct. Only a few days after launching GitHub authentication, there were already users signing up with it.
One of the NextAuth.js (v4) features is linking accounts for signed-in users. It led to creating one user with the primary email and then many linked accounts with different emails.
It also led to users having multiple accounts with the same email address if they signed up later with a non-primary email.
All of that caused more confusion and support tickets, so I closed it.
But with Better Auth, it should be irrelevant altogether since it links accounts by email. Anyway, it is still better to close the authentication flow for authenticated users.
Before the update, the error rendering was not very user-friendly. The toast message was used to display the error.
But did users see the error?
To make sure that users always see the error and can react to it, the error message is now displayed clearly right in the form:
That way, users will never miss it.
Often users forget which method they used last time to sign in. In general, it is not a problem, since ScreenshotOne will link verified accounts automatically.
For example, if your GitHub email differs from the Google email you used to sign up for ScreenshotOne, this might lead to creating an additional unnecessary account.
For such cases, it is better to know which method was used last time. There is nothing to lose in UX/UI, but only gain for users who return and sign in often.
Added terms of service and privacy policy links to the sign-up and sign-in pages.
In case if potential customers have any doubts or questions, they can read the terms of service and privacy policy and be able to figure out what they sign up for.
I migrated to Resend and subscribed to a paid plan even though I don’t need to.
One of the important features of the product for me is that its makers do take care of it.
When I got a transactional authentication email from Resend, I replied to it to check if they respond and how much time it will take.
They not only responded but helped me troubleshoot some other issues.
The same applies when I mentioned minor UX/UI issues—their founder replied that they will take care of it:
Also, DX of Resend is one of the best in the market, and it seems it will be cheaper for my needs than Mailgun long term.
It is a good practice to use subdomains for emails instead of the main domain to avoid losing sender reputation in case something goes wrong.
I configured a different domain for email sending to make it more recognizable and avoid being marked as spam—notifications.screenshotone.com
.
I will send transactional emails only from this domain, using the team@notifications.screenshotone.com
address.
I installed the React Email library to render emails with React and created a custom template instead of using the one provided by the NextAuth.js (v4) library.
Before:
After:
There is no drawback to blocking disposable emails.
Seriously oriented customers who see the value of the product and know why they are signing up never use disposable emails anyway and sign up with their work emails.
ScreenshotOne will not allow disposable emails when signing up anymore. In the majority of cases, they were used to sign up for the free plan and exhaust its credits.
However, users will still be able to sign up with email aliases.
While I haven’t seen paying customers signing up with aliases, or if it was very rare, I decided to allow using email aliases.
One of the organizations reached their max member count of 10, and I had to increase it to 50 to forget about it for a while. 50 members seems to be a good number for most organizations and it is way out of the typical pattern ScreenshotOne currently has.
An average organization as an entity in ScreenshotOne has 2-5 members, even when represent really large companies.
If you have any suggestions or questions, please feel free to contact at support@screenshotone.com
.
Interviews, tips, guides, industry best practices, and news.
Since a few months ago, it has been possible to check errors in the dashboard request log and get explanations and more details in the documentation. But!
A new and improved request log has been deployed. That is a good beginning of the week! Check out why.
There is a set of use cases when you want to fail screenshot rendering and retry it if the content of the page contains a string.
Exhaustive documentation, ready SDKs, no-code tools, and other automation to help you render website screenshots and outsource all the boring work related to that to us.