Entaggle – An Unconventional Approach to Implementation

About me

I have worked over SDLC for 25 years in various roles predominantly as a BA, system designer, tester and application support. Coding has not been my strong points but kept strong passion for testing not just testing software but also requirements and design. This is the first time I noticed unconventional approach to system design and implementation so felt it necessary that I should express my views for the benefit of designers and alike. The reason for telling you about me is so you know where I am coming from.

How it came about?

As a routine, I was checking my emails this morning (Saturday 5, 2011) when I noticed that Weekend Testing Session was about to begin and I accepted the invitation from Ajay to join. Interesting enough, weekend testers have been thinking about testing Entaggle all this week and here I was about to test this shiny new application. All day, I have been going through my testing results and of others to extract key lessons learnt when I realised that there is something important that should be reported before I report my full findings. I found to my horror that common design and implementation mistakes been made. I strongly feel that these should be brought to the attention for future reference. They are described under 4 separate headings for clarity.

Naming Convention

The mission charter was declared and we were given the go ahead to start testing Entaggle on the staging environment. As soon as I clicked the link provided and signed up for an account, to my surprise, I was logged straight away without having to wait for the confirmation email. For 20 odd minutes I kept touring the site before creating a new tag and successfully used option ‘tag someone’ to tag Ajay. I soon realised that something is not right and reported the problem to Ajay. By that time he had already established that we were given the wrong URL so he gave us a new URL. URL he gave us later was not different from the previous one except prefix www was missing from it.  Comparing the two URL I concluded that test and prod staging URL differed by www, a prefix that a browser would automatically add at run time when you type in the URL window instead of clicking a link.   In our case test URL begins with xxxxxxx.entaggle.com whereas prod staging URL is www. xxxxxxx.entaggle.com. I never seen such naming convention applied in system development. In all our projects, we played it safe by added a prefix test or dev concatenated to the environment name so there is no confusion. I am very surprised that this point was not picked up at an early stage. It is very easy to guess staging server URL from the prod URL, therefore, due care should be taken when naming environments.

Database Synchronisation

The other thing that surprised me even more is the manner staging and production databases are synchronised. If you sign in via the staging server and make some changes then they are visible through the production server and vice versa. I have not been able to establish how the two environments are configured, whether both environments use the same virtual image of the database or both environments are constantly synchronised in real time. If the latter is true then I find this really odd.

Vulnerability

After observing Entaggle for the last couple of days, I am at pain to point out that Entaggle is vulnerable to spams because contrary to my past experiences with systems, the login page is built without any check for users. If there are no checks made at the sign up stage to distinguish between a genuine user and a hacker then there is likelihood that the website can be hijacked very easily. I believe you do need captcha code entering box to establish that a real user is signing up for an account. My recommendation would have been to integrate Entaggle with various internet accounts such as Google, twitter thereby getting rid of sign up functionality altogether thus eliminating potential spammers accessing the website. The latter has the advantage of avoiding the option to change password or requesting instructions for confirmation email and associated validations that goes with it.

Audit Trail

I find it at odds that I can’t see whether audit trail is kept for all the activities a users perform when using the website. It is just possible that activity details are not openly made available to an ordinary user but I find it surprising that it is not traceable considering it is an open system. I can see the same activity being updated rather than keeping a history of the changes that a user makes eg if a user is tagged it appears in the recent activity list and subsequently appears as updated when the tag is accepted. Due to the limited number of recent activities displayed on the home page, it is difficult to tell which of the activities failed to apply. I certainly did not see declined requests making to the list which may be deliberate.

Summary

Some of the points highlighted above are avoidable if careful consideration is given at the design stage. It is very easy to fake environments these days so due consideration should be given while designing systems such as Entaggle. It can potentially damage someone’s reputation which if happens would have serious repercussions. As always the advice is that all potential risks can be mitigated with good planning.

P.S. Although this post was written two weeks ago but I decided to publish it anyway.  Some of the points raised in the Naming Convention Section above have been resolved after exchanging messages between Elisabeth Hendrickson and I.