Overview
FreeTime™ is a security-enabled desktop application that is used for finding mutually available slots between its users. This available slot will be displayed for the user to choose from, which will be reflected in his timetable using our FreeTime’s Graphical User Interface (GUI).
This project portfolio would be introducing you to my team that has developed this product in the span of a semester. In addition to giving you a brief general overview of this application feature, I would be going in depth into the details on how my own features are implemented. This is to give you a deeper understanding of what contributions that I have done within this project, and hopefully you would perhaps too be interested in this project of mines.
So sit tight, and let me tell you more about FreeTime, and how it will make scheduling meetings easier.
FreeTime™ Introduction
In addition to essential security features such as login and registering, we have a clean, minimalistic landing page that is user-friendly.
Users can import preexisting timetables that are taken from Google Calender or any other calender application that saves their data into the commonly used .ics format. This handy feature allows quick integration for users coming from other timetable applications that lack FreeTime's feature.
On top of having friends to look at their timetable, users are also grouped with groups according to what they have inputted. This is to easily select friends that are in the same group as you, which then sets the stage to find the mutually free slot among this particular group of friends.
| You can be part of multiple groups, or none at all |
Using the command freetime, you would be presented with a timetable that shows you what are your common free slots are.
Thus you are freed from the pains of finding a common free slot in huge groups.
Summary of contributions
In this section, I would be briefly telling you about my contributions to this project, and any interesting points that you could find useful.
-
Major enhancement: Added the ability to authenticate users within FreeTime
-
What it does: Allows the users to have unique access and control to his own timetable
-
Justification: To be able to prevent others from editing your own timetable, and to facilitate different privacy levels. Privacy levels are given to users to have control over what they feel comfortable sharing between strangers and friends.
-
Highlights: Implementing the above is not trivial as I had to rewrite how the commands are parsed and executed, which are then handled in SecurityManager. This is done on top of having to deal with new commands such as login, and restructuring old command into register. I had to understand and improve on all modules to make them to work together in this new sytem.
-
-
Minor enhancement: Used a hashing feature together with a salt to store user’s password in json format. This is to improve security by not storing users' password in plaintext, but encrypted securely.
-
Project Overheads
-
Project management:
-
Contributed to releases
v1.1-v1.4(4 releases) on GitHub
-
-
Enhancements to existing features:
-
Documentation:
-
Updated Screenshots in User Guide #192
-
-
Community:
-
My User Guide Contributions
A User guide is given to the targeted audience of the application, and usually is written in a step-by-step way to guide new users to use the application.
Given below are sections I contributed to the User Guide. They showcase my ability to write documentation targeting end-users. |
Registering and Logging In
Whenever you open the application, the timetable content and commands are locked. You are required to either login with a pre-existing account, or register a new one.
| FreeTime has a default user with username: test and password: test |
There are five security related commands that can be entered on this command line:
-
login -
register -
ui -
logout(Only when you have logged in) -
exit
At this page you will have to enter your credentials to log in. Only then would you be able to edit and view your own timetable,
and view your friends' timetable.
|
Friends are other users that you have "friended", and all users start off without
having any friends. |
The timetable that belongs to users that are not your friends will not be available for you to see, till you add them as friends.
Logging In: login (li)
Command: login u/USERNAME pw/PASSWORD
Examples:
-
login u/test pw/test
Logins with Username: test and Password: test -
login u/tim pw/tam
Logins with Username: tim and Password: tam
| You are required to to enter a password that contains more or equal to 8 characters. To ensure that your account is well-protected, do use a password that is not common. |
Registering: register (re)
Command: register u/USERNAME pw/PASSWORD e/[EMAIL] p/[MOBILEPHONE] a/[ADDRESS]
Examples:
-
register u/tim pw/tam e/tim@tam.com p/88888888 a/Tammy Road
Only the Username and Password fields are necessary, the others are optional and
you are not required to enter them.
|
Showing the UI Interface: (ui)
Command: ui
Entering the command ui will cause the Login Window to appear as seen in figure 4.
Clicking on the Register button changes your view to the Registration Window seen in figure 5.
Logging Out : logout (lo)
Command: logout
To use this command, you would have to be logged in first. Typing logout as seen in the figure below
return you back to the login page.
My Developer Guide Contribution
On the other hand, a developer guide is written for technical stakeholders that are interested in the implementation of the methods, and might be working on extending the project.
Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project. |
Security component
API : Security.java
The Security component is a module that ensures the users that are using the application are
authenticated, and an instance of an authenticated user will be created and stored in ModelManager every time a user
is logged in so as to allow the application to do user-specific tasks.
It also handles all the commands entered to check for security clearance. On top of that, it is able to hash passwords and save them into a file named users.json at root folder.
In Figure 9, AppUsers is an object that stores the list of AccountCredentials. This object is created when FreeTime runs. Storage Component will try to find a user.json file to convert that into the AppUsers object. If the file is not found, or the data is corrupted, this program will create a new AppUsers object with default Users in it.
More information is detailed below in Security Implementation.
Security Implementation
To begin this section, we would need to introduce the idea of a Authenticated User instance.
Whenever a user successfully logs in, or creates a new account, the application will create an Authenticated User in
Model. This User is an extension of the Person Class, which different part of the UI and SecurityManager will access it. One example would
be the friend’s UI panel, where FreeTime has to know the current user to display his friends
Current Implementation
This section will be broken down into
1. Front-End
2. Back-End
Front-End Implementation
-
CLI
CommandBox Class handles the command line interface, and passes every command to SecurityManager through the Security API. -
UI Prompt
Inside the UI package, there are two new windows created, LoginWindow and RegistrationWindow. Each Window would handle UI events such as clicks and passing relevant information to the SecurityManager similar to above.
Back-End Implementation
The Sequence Diagram when a user enters a command is seen in the figure below:
AuthReturn is a enum type that contains the following definition:
COMMAND_ALLOWED, COMMAND_LOGOUTFIRST, COMMAND_LOGINFIRST, COMMAND_ERROR;
The above figure shows the sequence when the AuthReturn is COMMAND_ALLOWED. When it is not that, there will be an SecurityAuthenticationException
thrown with the relevant message to the user.
CommandsEnum is another enum type that contains the method iscommandAllowed(). They are found in seedu.addressbook.commons package.
The figure above shows the steps when login is called after parsing the command (since login is a command too).
AppUsers contains an array of AccountCredentials, which has the attribute of Username and Password, and methods such isPasswordValid(). Here it also calls the static Hasher class, which takes the password and a salt to create the hash of the password.
Whenever a user logs in, the username is searched from userList returned by AppUsers. Once it matches a username, the input pasword is then salted and hashed (SHA-512), and finally compared to the stored hashed password. A boolean is then returned to the SecurityManager.
Design Considerations
Where to store Authenticated User object
-
Alternative 1 (current choice): Inside of ModelManager
-
Pros: All the methods in LogicManager can access User object
-
Cons: The concept of an authenticated user object should be inside SecurityManager
-
-
Alternative 2: Inside of SecurityManager
-
Pros: ModelManager does not have security related objects inside it
-
Cons: Logic and Model methods cannot access it
-
How to store user password credentials
-
Alternative 1 (current choice): To encrypt with a hash function
-
Pros: Password is protected
-
Cons: There is a slight computational overhead and code complexity
-
-
Alternative 2: Store the plaintext password
-
Pros: Less work to do
-
Cons: Anyone who have access to the credential file can have access to all the application users
-