Logins & Profiles

At CodeResort we provide various features and services to our users, based on various tools and technologies. It is our intention to present this largely as a unified whole, but sometimes that is hard to do - and sometimes it just makes no sense to do it.

For logins we made a very early decision to base it on email address. That allowed us to only require 2 pieces of information from our users; email + password. It was the lowest common denominator for all the tools and clients needed to work with CodeResort, and it provided the lowest level of entry for users to get started.

This makes email address the key for a dimension of our users infrastructure, and as such it cannot be changed. As any key, we could of course change it if we really, really wanted to. However, that would mean rewriting all parts of project history and would be both incorrect and dangerous to do. If we change person@companyA.com to person@companyB.com for all commits and all wiki and ticket history, would that really be correct? If person leaves Company A to take on a job at competing business Company B, would that make a new natural location for sending ticket notifications for old Company A issues that gets updated? Would it be right to reassign credit for thousands of hours of changes paid for by Company A onto Company B? Should the person retain access to all Company A projects in new role? We don't think so.

Any user that changes email needs to create a new login, and re-apply for access to the projects that now makes sense to participate in.


A natural consequence of the simple email-based key is of course that many decide to use a 'personal' email when registering, so that trivial things like changing workplace need not be an administrative burden. That's fine with us of course, you are free to use any valid email you want.

For project owners, however, this is somewhat less ideal. Being presented with a prdffdd13@hotmail.com address makes it harder to determine who this may be, a challenge that usually only becomes harder over time as people come and go in projects.

So, we came up with the concept of an optional "Profile". 'Optional' in so far that we do not require that you make one, but 'optional' in the sense that project owners may require it and only accept applications for access if you have such a profile that details your full name, place of work and basic contact details.

Link profile screenshot.

Your login is linked to this profile, and in fact the profile is a separate project just for you and your login where you may store your own information in the Wiki or use the Blog to publish facts and trivia. Through the personal project we also provide a 'My Tickets' overview page, and we hope to further extend personal projects with useful features soon.

Link several logins to one profile

A recent change we made is to add the ability to link more than one login to a profile. That means you can keep your profile ('person') and share it and access it from any of the logins you create. Moving from Company A to Company B does not mean you shouldn't be allowed to keep your own information. The details of this is available in the Admin->Logins page in your profile project.

Questions and Answers

Q: Why no Forms login? Why no descriptive forms? Why not use state-of-the-art web technologies such as OpenID / OAuth to perform authentication, instead of plain authentication requests? The simple answer is that the tools support just isn't there. There is no way to make a Subversion client perform a redirect or have it impersonate by accepting tokens and cookies. All it knows is the Basic and Digest authentication protocols. Same with the WebDAV support that allows you to connect file shares and map them as local disks. And the API that allows you to use simple tools to pull and push information. Whatever else we provided for our web-frontend we would still need to make a duplicate system that would work with all possible tools. So we have ended up sticking to the one simple way of doing it.

Q: Why can't I login using my 'handle' / shortname? We could have done that, but with profiles supporting more than one login this is not really feasible. Should we test password against any of the logins? Do we pick the first login that matches? The last? Or just make it random? What if you forgot your password, do we reset all logins or just pick one again?

Q: What if my company change name? So, what if the change from Company A to Company B is not about you changing but your employer changing? What if you get sold or merged into some new entity - or your employer just decides on a corporate name change? That is the one real-world scenario that complicates our simple rule, but we still do not have any tools to make such pervasive changes. Sorry.

Q: What's next? From the perspective of users and logins? Not much really. We'll keep using our simple scheme for logins and profiles, but keep enhancing the user experience as we did by introducing the option to link several logins to same profile.

  • Posted: 2011-03-21 02:50 (Updated: 2011-03-29 21:59)
  • Author: simon
  • Categories: news



No comments.