Introduction

The Internet is a wonderful resource for students and teachers everywhere. Our client, Mr. Brad Budinger, is a teacher who like to use the Internet to help his students learn as well as provide them a resource to research any and all subjects. Unfortunately the Internet doesn’t just have useful learning content, it has Facebook and Myspace, flash games galore, and some very school inappropriate content. Not only are there many sites which simply aren’t relevant to school, it can be difficult to find the sites that are relevant and contain truly useful information. On this note, good sites are difficult to share, between students, and from teacher to students. Sharing options are limited to writing a URL down, or telling a search path, which may change. These are just a couple factors that make the Internet less useful than it possibly could be.

Often the Internet is used for research as well. Research can be very difficult to keep track of since there are so many web pages that get visited. This is another area where it seems there is opportunity for improvement, the ability to track and keep track of useful web pages and notes associated with them in order to make time spent on the Internet more efficient and productive. Overall, Mr. Budinger is seeking a application which will make Internet usage in the classroom, more controlled, more targeted, and more efficient both in time and effort spent by students.

In order to address the current problems in the way the Internet is used in the classroom we propose an application which will provide many functions which will directly address Internet browsing. Tools such as notes associated with web pages, a general bibliography text area viewable alongside web pages, white listed web browsing, and a link libraries which can be targeted to subjects or age groups such as class levels. These tools will make for a simplified, efficient, web browsing experience which will be straight forward for younger students, and allow older students to take notes and record useful pages simply and with little work. Along with these browsing functionalities some other useful functionality will be included. Use accounts will be accessible from any location that has the application installed, there will be a tool which will allow for the submission of files/assignments which the teacher will then be able to download. Our application will also allow for significant control for teachers, such as controlling the white list, building libraries, and viewing students browsing history, notes, and accessing uploaded files.

We aim to build all this content into a client which will then interface with an authentication server as well as a database. The centralized database will contain all the information and data about users as well as uploaded files. The client will provide both the student and the teacher interface and allow access to notes, display the library in an easily accessible format, and provide for all normal interactions with the application. With ease of use in mind we will build an application which will become a tool teachers will want to use and students will find useful.

Architecture Overview

Components

Browser	This component is the encompassing application that contains all client-side components. It provides a minimal web browsing user interface.
Server Database	This server component consists of a database that contains tables pertaining to all aspects of the systems operation.
Client Authentication	This component provides the interface that allows users to log in and out of the system.
Server Authentication	This server component authenticates requests from Client Authentication.
User Manager	This component allows teachers to list, add, modify, and remove users from the system.
Whitelist Manager	This component allows teachers to add, modify, and remove rules from the whitelist.
Whitelist Accessor	This component grants or denies access to URLs based on the whitelist rules. It acts on every HTTP request made by the Browser.
Profile Synchronizer	This component tracks browser history and bookmarks and records changes to the Server Database. It also restores history and bookmarks (and other profile related data) on login.
Tag Manager	This component allows teachers to list, add, modify, and remove tags from the system.
Library Viewer	This component provides a user interface for students to browse library entries (bookmarks) provided by teachers.
Library Manager	This component provides a user interface for teachers to list, add, modify, and remove library entries (bookmarks) from the system.
Note Taker	This component provides a user interface for taking notes on the current URL. This component also allows users to upload files, tag the note, or mark it public.
Notebook	This component provides a user interface for listing and sorting all notes for all URLs.
Note Viewer	This component provides a user interface for viewing notes taken by other users on the current URL.
Commenter	This component provides a user interface for making comments that are attached to notes.
Comment Viewer	This component provides a user interface for viewing comments that other users have attached to notes.
Notification Manager	This component provides a user interface for teachers to change the MOTD, or to broadcast new notifications.
Notification Viewer	This component provides a user interface for students to view the MOTD and other notifications.
Bibliographer	This component provides a user interface for adding / removing the current URL from the bibliography.
Bibliography Manager	This component provides a user interface for listing, adding, removing, and exporting bibliography entries.

To give more detail into these modules, they are, in general, GUI components. Here are some examples as we currently see them.

Library Viewer

Note Taker

Bibliography

Notebook

Detailed Module Descriptions

The following are descriptions of modules as we understand them currently, this means that some modules have significantly more detail than others, and that what is stated here may change during implementation. For instance, the Authentication Server already exists, hence it is described in great detail, other aspects simply haven’t had the same time or detail invested yet.

A diagram of how we currently view our overall architecture as far as distribution and data flow.

Authorization

● Server Authentication Component: this acts as the server component, listening for authentication requests and responding to them.

● Client Authentication Component: this speaks with the server component in order to determine if someone should have access to the system or not.

Server Authentication Component

Goal: The goal of the Server Authentication Component is to authenticate users on login. It is a server that listens on a network port and responds to authentication-specific requests. These requests will take the form of modified HTTP.

Functions:

GET-NONCE /userid HTTP/1.1

This request will cause the server to generate and return a nonce for the given userid.

● userid: the id of the user who wishes to authenticate. This may or may not be a valid user; the server’s response is the same in both cases.

The server will respond OK<nonce> where <nonce> is a cryptographically secure random number.

This request will cause the server to attempt to login the given userid.

● userid: the id of the user who wishes to authenticate.

● cnonce: a client generated nonce that is a cryptographically secure random number.

● hashedvalue: the hash of (cnonce + hash(password) + nonce)

The server will respond YES when authentication is successful and NO when authentication is unsuccessful.

Client Authentication Component

Goal: The goal of the Client Authentication Component is to authenticate users on login. It is responsible for contacting the server component with a given set of credentials. It grants access to the system after receiving an affirmative response from the server, or blocks access to the system after receiving a negative response.

Functions:

user object

This is an object that defines the currently authenticated user. This object will be used by other components to determine if a user is logged or authorized to perform an action.

name: the name of the user

authenticated: true, user has authenticated; false, user is not authenticated

level: 0, a student-level user; 1, a teacher-level user

modal login dialog

This is a modal dialog that displays a user interface for entering username and password. The dialog is displayed when the application starts and after a user logs out.

Moving past this dialog is only possible by entering a valid username and password. Canceling the dialog causes the application to close.

change password dialog

This dialog displays a user interface for changing passwords. The dialog can only be displayed after a user has logged in. The dialog prompts for the old password, and the new password typed twice.

logout ui

This user interface provides a method for users to log out. This user interface also displays the name of the currently logged in user.

auth(username : String, password : String) : boolean

This function will attempt to authenticate a given username and password.

● username: The name of the user who wishes to authenticate.

● password: The password of the user who wishes to authenticate.

This function will return true if authentication was successful, or false if authentication was unsuccessful. The user object will be configured on successful authentication.

logout : void

This function will logout the currently logged-in user.

The application will forget user-specific data, returning the user interface to its default state, spawning the modal login dialog. The user object will be reset.

Java authentication server classes and their methods.

User-Manager

User-Manager Component

Goal: The goal of the user-manager component is to provide a user-interface for users who are teachers to list, add, modify, and remove users from the system.

Functions:

main ui

A user interface that consists of a list or table widget, an add button, a modify button, and a remove button. This user interface will list objects of type UserObj. This ui is only accessible to users who are teachers.

add/modify ui

A user interface that consists of a name field, a “is teacher” checkbox, an add/ok button, and a cancel button. This user interface will act on objects of type UserObj. This ui is only accessible to users who are teachers.

UserObj

A type of object that defines information for a user on the system. The user interface configures these objects and passes them to various functions (add, modify, remove). The user interface also lists and displays these objects in detail.

user database

A database consisting of userids and corresponding usernames and ‘is teacher’ flags. This database is accessed by other user-manager functions to populate objects of type UserObj, and to apply changes from objects of type UserObj.

listUsers() : Array<UserObj>

This function will attempt to list all users; only users who are teachers may list users.

A list of objects defining users will be returned and displayed by the user-interface.

addUser( user : UserObj ) : void

This function will attempt to add a user to the system; only users who are teachers may add users. The user is defined using a UserObj which has been configured by the user interface.

The database will be changed to reflect the information contained in the UserObj.

modifyUser( user : UserObj ) : void

This function will attempt to modify a user of the system; only users who are teachers may modify users. The user is defined using a UserObj which has been configured by the user interface.

The database will be changed to reflect the information contained in the UserObj.

removeUser( user : UserObj ) : void

This function will attempt to remove a user from the system; only users who are teachers may remove users. The user is defined using a UserObj which has been configured by the user interface.

The database will be changed to no longer contain the information corresponding to the UserObj.

Whitelist

Whitelist Component

Goal: The goal of the Whitelist component is to validate requested URLs against a valid list of URLs. A URL is either on the whitelist and valid, or not on the list and invalid.

Functions:

whitelist ui

A user interface that displays the whitelist and allows adding and removing rules. This user interface is only accessible to users who are teachers.

whitelist database

A database consisting of ids and corresponding definitions. Rules may be simple URLs or more complex patterns defined using regular expressions. The other functions in the whitelist component access this database.

isValid( URL : String ) : boolean

This function will check the given URL against the whitelist.

The value true is returned when the URL is on the whitelist. Otherwise the value of false is returned. This function must be called for every request made by the browser component.

addRule( rule : String ) : void

This function will attempt to add a rule to the whitelist; only users who are teachers may add rules. A rule can be a simple URL or a more complex pattern defined using regular expressions.

The rule will be added to the whitelist if the user is a teacher.

removeRule( id : Integer) : void

This function will attempt to remove a rule from the whitelist; only users who are teachers may remove rules. The rule is specified using an integer id that is a valid rule in the database.

The rule will be removed from the whitelist if the user is a teacher.

modifyRule( id : Integer, rule : String ) : void

This function attempts to modify a whitelist rule; only users who are teachers may modify rules. The rule currently defined by id will be replaced using the new definition which can be a simple URL or a more complex pattern defined using regular expressions.

listRules() : void

This function will attempt to list the rules in the whitelist; only users who are teachers may list rules.

A user interface will display a list of integer ids and corresponding rule definitions.

DatabaseHandler

Goal: Provide all required database interaction functionality. This means pulling down information as well as adding information to the database.

Functions:

updateWhiteList ( WhiteList ) : void

Update the database’s whitelist with the new whitelist provided.

addToWhiteList ( QString ) : void

Add an entry to the current whitelist.

removeFromWhiteList( QString ) : bool

Remove a given string from the whitelist, return success or failure

updateTagList( QString ) : void

Update the tag list with additional tags

addTag( QString ) : void

Add a tag to the existing pool of tags

removeTag( QString ) : bool

Remove the given tag from the list of tags, return success or failure

updateUserList( UserList ) : void

Update the given userlist to reflect the current database contents

addUser( User ) : void

Add a user to the database using the User object

removeUser( User ) : bool

Remove the given user from the database, return success or failure

modifyUser( User ) : bool

Change fields about the given user withing the database, return success or failure

changePassword( User, QString ) : void

Change a users stored password

updateNotificationList( NotificationList ) : void

Update the given NotificaitonList to reflect the current database

addNotification( Notification) : void

Add a notification to the database

removeNotification( Notification ) : bool

Remove a notification from the database, return success or failure

Lists of fields and methods within a couple classes and and example of usage.

Part of this design involves several container classes to contain information from the database, as of yet these are undefined but will roughly mirror the database tables described below. An example of these classes would be Note and Notes, Notes will contain many Note objects, each of which is just a single instance of a note and URL pair. As the project progresses we will describe these classes and their interfaces. However, because of the focus on creating a working product we have sacrificed some documenting for a quick return, and because of this, already have a working web browser and shell components which are laid out to handle displaying content which will be pulled from the server.

Database Design:

Tables:

User

UID : enum

name : char

isTeacher : bool

isLoggedIn : bool

isGroup : bool

idList : char

noteID : enum

bibID : enum

The user table consists of all the users of the system. There is a uid in order to keep track of users more easily in the sytem. The name is simply for users to see names rather than an id. In order to determine if the user is a teacher or not, the isTeacher field is used. This will help determine if the user needs to see administrative functionality or not. isLoggedIn will be used to see if a user is logged in. This will be used for things such as indicating a user has an update. A user entry can also be used for a group by setting the isGroup field and listing out the id numbers of the users in the group in the idList field. The user table also contains two fields, noteID and bibID, that point to the note and bibliography tables for the user.

Whitelist

rule : char

The whitelist is simply filled with many rules for different web sites that can be visited by users. The rules can be either a URL for a specific site or a URL with the wildcard symbol (*) which indicates that anything can be placed where the wildcard symbol is and be a valid site to go to.

Library

name : char

url : char

category : char

desc : char

The library tables are used as subsets of the whitelist to create smaller views. The table contains the name, URL, and description of the site the entry is for. It also contains a category or list of categories that the site belongs to.

Bibliography

UID : enum

title : char

author : char

date : char

url : char

The bibliography table will hold a user's entries for their bibliography. It contains the UID of the user it is for, the title, author, and url of the web page, as well as the date when the web page was found. This is all stored so that the user can create a text document of the bibliography when they are done with the document or assignment.

Notes

UID : enum

isNote : bool

content : char

isPublic : bool

author : enum

title : char

filepath : char

tags : char

The notes table contains all of the notes and comments for each user. It is one table to hold both the user's notes, as well as the comments by other users on the notes. All notes and comments for a user will be given the user's id in the UID field. The isNote field will distinguish the entry between a note and a comment. The content field stores the text of the note or comment. isPublic is used to specify whether the note is viewable by all or not. The author field keeps track of who wrote the note, this could be different from the UID for comments. The title field stores the user specified title. The tags field will keep track of any tags given to the note for organization. Finally, the filepath will keep track of any files uploaded into the note for file submissions. This field won't be used right away, but will be there for later functionality.

Notifications

text : char

author : enum

recipients : char

timestamp : timestamp

The notifications table will keep all of the notifications made. Each entry will have the text of the notification, the author, the recipients, and a timestamp. The author will be a UID of the user that created the notification. The recipients will be a list of UIDs that the notification will be displayed to. The timestamp will be used for deleting old entries.

Implementation Plan

The following is a rough plan of the order in which things will get implemented, and who will be working on them. Tasks in the near future are much more accurate than plans a month out which will depend upon previously completed tasks. The big picture is we aim to have a nearly completed project by the end of March so that we may test and finish refining the application in April.

February

March

April