Linking users and accounts

Damian Jakusz-Gostomski — Thu, 16 Jul 2009 20:01:08 +0000

There are many ways to handle user authentication with the system. The authentication can take place at a per project, per company/client account or at a user account level. The pros and cons of each method will be discussed below.

One account per project

In this scenario, every time you want to create a project, you need to enter a new set of credentials. Although you may use the same combination of email/username and password for each one, you will also need a unique way to link these to the project, which means you need to remember the project ID or some vanity URL. The advantage of this is you can keep separate projects totally isolated from each other, so work and personal projects do not get in the way of each other.

Even if you had a nice, easy to remember vanity URL, as soon as you have more then one or two projects, keeping track of all the URLs would not be easy, so you’d have to bookmark them, which results in a loss of portability in most cases, which is one of the key benefits of a web app. On the plus side, as you can have a separate set of credentials for each project, you can have notifications from different projects going to different email addresses.

On the whole, this method seems to be more hassle then it’s worth, and it’s possible to get the same benefits to an extent with the following method.

One account per company/client

In this scenario, you will have one or more accounts, which can have the same set of credentials or different. So you may have an account for work which groups all your work related projects together, then you may have a personal account which groups all your personal projects together and so on. This greatly reduces the number of accounts in total, which makes it much more feasible to have vanity URLs. You still have the clear divide between work projects and personal projects. The one downside is if you end up with a large number of accounts, your resources get spread across multiple accounts, which makes finding what you need a little more effort.

One global account

In this scenario, you only have a single account which houses all your projects. This has the benefit of everything being in one place and only one set of login credentials to remember. It also removes the need to remember any special URLs. Even with this method, there is still the need to have company/client accounts, but it would be possible to select which one you want once you login to your master account. It would also make it much easier to switch between ‘accounts’ as they’re all in one place.

Conclusion

The benefits of the 3^rd method exceed those of the first 2 and it still provides the separation of accounts within the master account. The master account is just an entry point into the system, as oppose to a replacement for multiple company/client accounts.

Users Intro

Damian Jakusz-Gostomski — Thu, 16 Jul 2009 10:57:45 +0000

Users, along with accounts is an area of functionality which isn’t very exciting, but is still needed. The reason it’s needed is because each user of the system needs to authenticate with the system before they can access information relevant to their projects. Without user separation, everyone would be able to see everything, which might work in a small, open environment, but would never work on something the scale of the internet, as most project information is confidential, and kept between the people involved on the project.