🤓 Projects

I feel like creating an MVP web app this week. As in… work on basic features that I wrote down, write the code, do the frontend and ship. One week. Think I should do it? I would naturally blog about it.

Just to keep my mind busy, I’ll be announcing yet another personal project that I’m working on. Hope to share more next week. It’ll be a web application. Aimed mainly at developers, creators and small businesses that have their own apps and sites.

Continuing from the registration section, I started working on the Login part last week. There were a few more moving parts here as I had to cover both a password login and of course a magic link login. As I was completing it and testing it there were a few edge cases that had to be dealt with also.

A form is born

You start with your normal email form:

Nothing special. I’m not really a fan of having email only first and always prefer when there is a password field also. However, as we have to deal with both passwords and magic links, this was for the best.

Pressing “Go” will check the email to see if it’s valid and that the account is active. Next it will check what type of login you have. That means either magic links or passwords. Here is the magic link screen:

I’ll probably change the wording here. Once you receive the email, you tap/click on it and you’ll be on your way. Magic links are only valid for 15 minutes.

For password logins I will show you the below:

Easy enough to navigate. There is an addition of a “use magic link” button. This will send a magic link your way, just in case you forget your password. This also sets your login method to be magic link only until you change your password.

Once you’re all confirmed with email, password and/or magic link, you will have to enter your one time passcode:

I still don’t have back up codes set up and I’m thinking of doing something else to facilitate that, so for now I just say to email me. I could trigger the two factor set up on the account once again.

To be honest, you shouldn’t be loosing your data - but I appreciate that it can happen - so I will work something out to make that less painful.

Some edge cases

As with everything I tried to think of a few edge cases along with the ones I came across. For example, when you register there are certain steps to take - but perhaps the user didn’t finish all of them. In that case, depending on the registration step you were at, it will ask you for details that you certainly know for example your email and password, but then it will go ahead and redirect you to the correct registration step to continue. As you probably don’t have any data/servers set up, unless you have finished the sign up, I think this is a good compromise.

All new accounts start with a magic link login, so even if you haven’t chosen you will still be able to login and continue where you left off.

I still need to implement failed logins attempts to disable the account. The database already includes the counter column, so it should be easy to add that.

Next steps

That’s it for now on registration and login. I would call it feature complete. The next task is to think about the Dashboard section - I didn’t have too much brain capacity to think about that just yet.

I wanted to write this post last week; kinda weird times at the moment. I’ll try and keep it more regular in the coming weeks.

Thanks for reading, and if you have any input… let me know!

Just completed the login section and logic for Picard.sh. Pretty happy that it's done now. Going to do a write up tomorrow at some stage. Hoping to use it on another project, so I took care to get it right.

Quick update on Picard.sh: Completed the login flow for magic links. Was harder, but certainly more entertaining, than I initially thought. Tomorrow I’ll try and complete the “password” login flow. Two Factor auth already working too.

Good progress.

Spent an hour this morning to add “Team” support for Picard.sh. Kept it simple for now as I don’t intend to role out with it on launch - just happy it’s there now than later.

Yesterday, I exclusively spent the day on finishing the registration process for Picard. Just to recap from the last blog post, I wanted to give users a choice of either a password login or a magic link. I think that gives users the flexibility.

I choose you password

Magic links are good, but if you want a password you can do that too. Personally I prefer magic links because I don’t need to know about the password at all, and as they are one time use - it’s more secure (so I believe… “A password you don’t know is the best password”). However I totally get it.

So, you can do that. Here is the password screen:

Nice and simple.

Note that I don’t enforce specific rules, they can be as long as you want… or as short as you want. However, here comes the great part. All passwords (or specifically part of the password hash) is sent to HaveIBeenPwned (https://haveibeenpwned.com/Passwords).

Note that no full password is ever sent to their API at all! It is only the first few parts of the password hash. This in turn returns results of passwords that have been used in the past during known breaches. The results bring back the last part of the password hashes that started with the first 5 character hash I sent through. This way I can check locally if any of them match your password. If so, Picard will reject your password and deems it unsafe. If you’re interested, 1Password uses the same practice to check against bad passwords.

I think that’s the best type of password enforcement rules I can think of. Perhaps I’ll go a step further and specify some basic rules. Although I always found it off putting when I went to a site that had several bullet points of bad advise. “Must contain 8 characters but not more than 30” blah blah blah.

I guess I could suggest a password that they can use… so that the user doesn’t have to take a wild stab at it. Although Safari is pretty good about suggesting passwords.

Anyway, I think having it hooked up with the above is a great combo.

Of course I also have a double check in place so that you confirm the password you typed beforehand is the same:

On top of that, it brings us nicely to the next point!

Two Factor Authentication is required

I made the decision that Two Factor Authentication is mandatory for both magic link logins and password logins. At the end of the day we are dealing with servers, and most likely customer data. So I’m making it mandatory that you set it up as you register. There is no way around it.

You’re going to be dealing with data in a database, which most likely includes customer data. To avoid, and fend off, any unauthorised access to your Picard account you’ll be required to authorise certain actions with your one-time passcode. That includes logging in, or other account options.

Here is an example screen running locally on my machine:

Each QR code is generated as your account is created. Once scanned, you will have to submit a valid token in order to proceed. That is rendered via SVG and is never saved locally as an image!

This was quite fun to do.

Initially I wanted this option only mandatory for password logins, but it dawned on me that everyone should benefit from this. In a way it gives me less logic to write later on if you did want to enable it for magic links.

I have a plan, in my head, about account recovery if you did ever loose access. Although it’s the 21st century, and you should hopefully be tech savvy about things like this (considering you’ll be running your own servers).

Anyway, I’m happy with the way it worked out and I prefer better security practices from the start. I worked with many clients, past and present, and it scares me how some of them secure their stuff. Just like flying aeroplanes… you never know who is going to be flying with you up front (trust me, I know). So, just a friendly hand from one developer to another to do the right thing from the start.

Pain point? Nope. Security is paramount!

Thank you page

After you have confirmed your token, you’ll go to the “Thanks” page:

I’m not sure if I will add this step closer to release… it’s there for now. It serves a few purposes.

One is to say “thank you”, the other to say “Hey, you have an AWESOME 30 day trial” (unlike everyone else out there) and to send a confirmation email out if your email hasn’t previously been verified (basically everyone that didn’t come from the “pre-register” phase).

Next steps

For the next step I need to work on the login phase of the project, which includes several things like magic link emails and forgotten password links etc.

Hoping I have that done by next week at some stage.

I’m always thinking about the “dashboard” design (called “Bridge” for now)… it’ll certainly be different than what you see at the moment during registration and login.

Another thing I want to work on is much better wording. I think it’s OK at the moment, however it can be improved. I think 40% of my commits to the project are word changes!

Anyway, thanks for reading. More very soon.

You can find Picard.sh here and sign up on the invite list.

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.

Spent a few hours working on Picard.sh today. Felt good. Going to do a small write up tomorrow about it.

Just working on database design. Nice to do something a little different.