As Rory discusses the data processing with Mary, another issue is raised. Mary becomes concerned that other people will start altering her data. She asks how she would be able to find out who had over-written her entries.
System logs can be used to search for and correct errors that occur within an application. However, often they are not so useful for tracking an individual user's use of the system. Another thing to consider is that with web applications, it is not straightforward to track who has accessed the application. To preserve anonymity on the Internet, web systems tend not to pass user information back and forth unless specifically configured or requested to do so.
To track and control who can access and change data we must both, log activity and identify end-users. To do this, the solution is usually to force users to log onto the application and thereby identify themselves. However, there are two issues with this. First, providing a log-on utility and systems to prevent unauthorized access to the application adds complication. Second, there can be resistance from users to log on as it can be seen as an unnecessary inconvenience. Therefore, it is worth identifying levels of authentication and user access logging, and then selecting the level that is most appropriate to the current need.
There are two main reasons why this level of authentication is appropriate. First, the application is very basic and ease of development outweighs the requirement for monitoring user activity. Second, total refusal of key users to having a log on process (for example, if in spite of your best arguments, the person who pays your wages insists that there is no user log-on process, you have little choice but not to have one).
There are three things to consider in this situation, to provide a minimum of logging information with the minimum impact on development and use of the application.
- Log the creation and last update of a data entry. Ruby on Rails has automated systems that will update "created_at" and "update_at" fields with appropriate times if these fields exist in a data table. Therefore, always include these fields in your tables. Knowing when a problem occurred is far better than having no information about a problem. In fact, it is surprising how much easier it can be to track down the source of a problem if you know precisely when it happened.
- If users refuse to use a log-on, consider tracking usage via their IP address. IP addresses are passed from a user's browser to the server within the HTTP header and therefore are fairly easy to detect and to use in a web application. Within the confines of a company network, it is straightforward to identify a user's computer from its IP address (even when dynamic addressing is in place) and to track the user from there. IP address tracking is not perfect (for example, if two users use the same computer, the system will not be able to differentiate between the two), but it is far better than having no information to track user activity.
- Add either a free text entry (if users vary a lot) or a selection drop down (if you can maintain a list of all users) that allows a user to simply identify themselves when they enter or alter data. Include a
"last_user"field in each table and store the user's entry in that field and/or include the user information in any log entry. Without a password or similar authentication process, it will be impossible to rely on the integrity of this input, but in my experience most users will use such a system and the resulting entries can be useful when tracking down problems. If you use the selection option, you can use cookies to remember a user's last selection. This makes the system easier to use for the user, and therefore can encourage them to use it properly, rather than just pick the first selection item they come to.
With this system, you will not be able to provide different levels of access to different users. If different levels of access are required (for example, to allow data update access, or higher level reporting), the users must identify themselves, and a log-on system is the best way to do that.
This level of authentication is workable within the restricted area of a company intranet. However, exposing a Ruby on Rails application to Internet access with no authentication in place would be extremely unwise.
The simplest authentication system is to add a password field to all data entry and update forms. When the form is submitted, the password is checked against the stored password and data is only entered into the system if the passwords match.
In its simplest form, everyone with "create" or "update" access uses the same password. In this case, the use of a password would not allow the system to identify and log who had edited the data. However, you could give each user his/her own password and then identify the user by the password added, or add a simple user selector as described above.
If you use this system, consider these recommendations:
- It is a good practice to change the password regularly and enforce a minimum level of complexity to passwords. For example, a policy may ensure that passwords are at least eight characters long, contain numbers, and both upper and lower case letters.
- Always create a system that allows either you or a designated user to securely change the password. At some point, you will need to change the password. If you do not, most users will come to learn the password and it will become redundant.
This is the simplest system to create two level access rights: those two levels being read-only for those who do not know the password and full access for those who do.
It is worth considering that if data is entered and updated often, this authentication method is actually more inconvenient than a log-on system, as the password has to be entered every time a form is submitted. Therefore, its use is best restricted to simple systems that are rarely updated.
As the application does not need to track the logged-on user, this system is simpler to create than a proper log-on system. Therefore, it can be useful to use if you need to get an application in place in a hurry, or as a quick way to add simple password protection to a system that previously had none. Especially, as a temporary stage to provide some protection while a log-on system is developed.
In most circumstances, the best way to control access and log activity is to use a log-on system. A log-on system comprises three elements: a storage area—containing a list of all users together with their authentication credentials (typically their password); a log-on system—where a user can enter their log-on credentials and thereby log-on, and a way of tracking and maintaining the logged-on status so that the user is not continuously asked to log-on.
This system is more complicated than the other systems, but the extra effort is worthwhile. Maintaining the logged-on status and controlling access based on that status is usually the most difficult part of a log-on system. However, tools built into the Rails framework help make this option relatively straightforward.
- If users are allowed to change or specify their own passwords, consider enforcing basic password conditions such as forcing a minimum password length of 8 characters and use of upper and lower case characters, and numbers.
- Log-on status can be stored within the session. This allows a user only to log on once each time they use the application. We can use cookies to remember the user so that log-on screens have that user's name preselected next time they access the system. Then they only have to enter their password to log on. That will make the process easier for the user and they will be happier to log on more often.
- Think about what you want to protect with a log-on system. For many systems, we only need to log and control adding, editing, and deleting data. Therefore, if a user only wants to read some data, they may not need to log on.
I strongly recommend that you create and use a log-on system!
One of the best things about Ruby on Rails is how easy it is to reuse processes and simplify common tasks. A good example of this is how easy it is to reuse a log-on system once it is created. All it takes is a couple of lines of code in a new part of an application, for that new part to implement the log-on functionality.
To get the most out of a log-on system, we need to record some activities that users carry out. We may not want to create a log entry every time a user views data, but with most applications we will need to log when people add, change, and delete data. For most cases, we probably do not want to record everything. What we want is to be able to audit the use of the system, both to track down problems and to provide reports to managers.
To achieve this, we need to create a new data object: the access history. As a minimum, this data object should include the following:
- The identity of the user who carried out the action
- The time the action occurred
- A description of the action
- The condition of any status after the action occurred. For example, in a project tracking system, we will want to log when the status changed to "project completed" and "customer billed".
We will also want to consider how to display this information and who should have access to it. Fortunately, a dynamic access-controlled web page is a splendid way of displaying such information. Therefore, Ruby on Rails provides an ideal platform to provide information on the access history.
Often, we need to be able to report on the access history of both individual objects and overall access history. For example, a team manager will want to see a report that keeps them up-to-date on how their team has been using the system. They will want reports based on all activity. For them, systems that generate period totals will help them create reports for their superiors. On the other hand, a project manager will only want to see the history of access to specific projects. Therefore, consider who will need activity reports from a system and be prepared to provide different information to different groups.
The person managing the system (in small businesses that is often us, the developers) will need a set of tools that lets them pull out the information needed to track down problems. Therefore, we need to be able to follow individual processes through, whether that is by following a user's progress, isolating changes to a specific area, or view data for a specific small period of time. We could do this by viewing the underlying data, but if we can create report and search systems that easily aid us in these tasks, this time will be very well spent. Also never forget, that while we may be the person managing the system now, it may be someone with less intimate knowledge of the system who manages it in the future. Leverage Ruby on Rails to make the administration job easier and we will all have more time to concentrate on more interesting tasks.
As speed is of the essence in Rory's project and most users will require read-only access, he decides to implement simple password access for the application, prior to his deadline.
For the immediate requirement this is a satisfactory solution. However, Rory is conscious that once the system goes live and people start using it, more people will want to add and update data. Upgrading access control to a log-on system will be a requirement for the likely second stage of development.
Rory discusses this with Mary and explains why he is developing access control in this way. She readily agrees to Rory's strategy.
However, Mary also asks Rory a question that makes him realize there is something he's missed: "How do we stop users putting in invalid data?".