Vincent Ritter

Picard.sh Project Diary - The Registration process

It's totally been overdue, but here I am with an update on Picard.

I'm not going to lie, I let this slide a bit after some pressure on getting Gluon out the door and a fair amount of client projects. So, here I am with some progress.

Let's get to it.

The registration process

I spent some time, over the weekend, to work on the registration process. There were a few screens designed already, but they had zero functionality.

The database design was already complete from my past self so all I had to do was write the code and make it work.

It's not complete yet, however it surely is getting there.

Registration is always weird and everyone does it differently. For Picard I wanted something that was quick to get in to, yet be safe to you. Managing your own servers can be tricky and using a third-party, like Picard, sure makes life easier.

However, with convenience comes responsibility.

When you're running a server that usually means you also keep personal information on it. That means that you should stay secure from sign up to deployment. As Picard acts as a front end to all your servers, I don't just want to allow the user to set any password they wish and be done with it. That just opens up headaches with keeping your account secure.

With that in mind, here is the flow of registration I have in mind:

  • Set your email
  • Set a name
  • Set password preference
  • Setup OTP if using a set password

The first two are easy, just set an email and then set your name. For email signup, during the beta, it will check if you have pre-registered or not. Only valid emails and pre-registration tokens can be used during pre-registration. You will get an email with that once I send out the first invites. If you want to set a different email during that process, you're more than welcome to.

Here is a screenshot:

Easy enough to get your started. Not shown is some extra text in the description, when using a pre-register invite link, saying that a different email can be used. You can see a screenshot of that here.

Next up is the Name field, keeping it simple:

This is just to keep it all nice and human. That name can be anything that means something to you. Your actual name is a good start. It will play a role later on. It's a mandatory step.

To note, all data is encrypted in the database, here is a preview from my local machine:

Note that my local, staging and production database all have different encryption keys.

Once that is set, we come to the password selection screen. This is slightly different than what you're used to normally, and I give you a choice of what you want to do.

Two options:

  • Use magic links
  • Use a password

Personally I prefer magic links, but I totally see the need to set your own too. So here I give you an option.

Magic links

If you choose magic links for log-in, you will receive a link via email every time you want to log into Picard. A great side effect here is that you will never know your password... and it constantly changes - so it's never the same.

Password

Some of you prefer to set your own password, and I totally get it! In this case, you will go ahead and enter your own password during registration. Here I am planning to also check if the password hasn't been pwned before and if it's secure. That means I'll check the database at Have I Been Pwned before allowing you to proceed. 1Password also uses this feature to check against "pwned" passwords. To note, the password is never sent to Have I Been Pwned.

On top of setting a password, you will have to enable OTP auth at this stage. This is mandatory when using your own password.

This might sound like a headache... sure, however your and my safety is more important to me.

Of course, nothing ever is totally safe. However we can go some way to make it harder to gain unauthorised access to your account and servers.

More auth options

This hasn't built yet, however I am also planning to add OTP auth for magic links for extra security. This isn't mandatory at the start, but can be set later on in settings.

On top of this, I am also researching the use of WebAuthn. Which basically allows you to use security keys and other methods for authentication where supported.

Back to the registration process

So now that we have the lowdown on options, here is a screenshot of the password preference screen:

I highlight the magic links, as they're convenient. Gently nudging you in that direction. Depending on what you select, you'll go to the next steps. Which are yet to come.

One note on registration, once you entered your email and advanced to the next step you're already logged into the account automatically. So if you decide to leave and come back later, you will be redirect to the correct registration process. So I'll double check which step you're at and redirect as needed.

Next steps

That's as far as I got over the weekend. It's been fun working on it so far. It's also fun to work on the frontend and backend at the same time, which is a nice flow. With Simple Schedule I built out the frontend first and then the backend. This worked fine and gave me a clickable prototype... however it also introduced wasted work for features that didn't make it.

For this week I am planning on finishing the registration process for both magic links and password setting. I'll probably also then work on the login part.

That's it for now.

Stay in the loop

Subscribe to the RSS feed...