New BIRCH registration system

From Bioinformatics.Org Wiki

BIRCH (getbirch/biolegato) registration

Currently, users have the option of clicking on a link to perform the BIRCH registration online. Brian has brought to my attention that the implementation of this system is extremely insecure (could possibly be exploited by spampots, etc):

I have come up with a proposal for a new registration system that I think will be simple to implement, more secure, and more effective.

Registration System proposal

Right now we have one way to register BIRCH, through the website. I think that we can augment this by offering 3 possible ways to register BIRCH:

1. Getbirch Registration option:
   1. User downloads and starts getbirch
   2. During the download phase of getbirch, the user is prompted with a registration window, that kindly asks them to register
   3. The registration information is inserted into a template email (ie, a mailmerge) and this is sent to a registration address, maybe something like "birchregistration@ccu.umanitoba.ca"
2. Biolegatio Registration option:
   1. Give the user to register from within Biolegato (under the "help" tab perhaps?)
   2. Runs the same registration app as in getbirch, a carbon copy of the code
3. Existing web registration option:
   1. Modify the existing CGI script to send an email (possibly using the backend for the app to do so, for simplicity)
      1. How difficult would it be to modify the CGI script to call a jarfile (passing the fields (name,email,etc) in as parameters)? If this is on the order of a simple modification, we don't have anything to worry about, as all the hard stuff has already been taken care of.
      2. It would be nice to use the same backend, to keep things consistent across the 3 registration methods.

Here is how I envision this working:

A "dummy user" would be created that takes the registration information from the emails it receives, and organizes them however we so please (I think appending them to a "registry", ie, a clear text file, should be sufficient).

• This "registry" could be group readable by BIRCH developers, but it shouldn't be world readable!
• We can create a simple script to notify the users that wanted to be kept up-to-date when a new release is created.
  • It could even be executed by the "buildrelease.py" script, so that users would be automatically notified when a release is created!

Implementation details: To implement this new system, we will need to do the following:

1. Create a new user on the ACN machines for the sole purpose of handling the registration emails (we can do whatever we want with the emails once they've been recieved: generate statistics, etc)
2. Write a simple app to send the registration information: <ESTIMATED DEVELOPMENT COST: a few days>
   1. All we will need is a simple GUI pane with text fields for user input<DONE- but its a dead GUI, see below>
   2. There is an existing java mail API for us to exploit<DONE - I wrote a quick app back-end to see how hard it would be, it was really easy!>
3. Write a simple script to handle the registration information/statistics, run by the "birchregister" user created above.
4. Merge the created app into getbirch/biolegato <Biolegato would simply need a menu entry to call the "birchreg.jar" jarfile>

I have drawn a dead GUI that would act as the frontend to this registration system:

I also took the liberty of testing to see how hard it would be to send mail using java, and have created a class that does this using a (free) gmail server.

Basically, all that would be left to do is connect the GUI with this mail sender, and then write some scripts to handle the received emails on a cron job.

• It would just cut the information from new registration emails, do some sanity checking (valid emails formats, etc), and then append it to a "database" (text file) of registered users.

Extensibility:

• We don't just have to keep track of registrations, we could send a different type of email each time a file is downloaded by getbirch and keep track of these statistics internally:
  • For example, when a file is downloaded, an email containing the filename string could be sent, and an analysis daemon could parse this out and increase an internal counter for how many times that file has been downloaded.

Final notes:

• I think that this approach is good for a few reasons:

1. Low implementation cost!
2. Take advantage of an extremely efficient and SIMPLE communication protocol (email!)
3. Secure! We can lock down all the information and stats in the "birchregistration" user account
4. With any luck it will increase registration and help us justify more funding!

Input/suggestions/ideas: Please put your ideas/feedback here!

Resources

• java mail example
• java mail example
• sun documentation on java mail
• eclipse visual editor project (VEP) - for gui building