-
Notifications
You must be signed in to change notification settings - Fork 2
Web Server
Written By: Martin Nikoltchev
The web server program is a web application that runs on Play! Framework. Play! Framework provides the underlying infrastructure for our application.
To run the web server in a development environment, install Play! Framework from the website linked above, navigate to the root directory of the project, and type the following command into your terminal:
$ play ~run
The above process will run your application on localhost (usually 127.0.0.1). Opening a browser and navigating to http://localhost:9000 will connect with the running application. More tutorials available on the Play! Framework website.
To launch the application on the internet, the project folder must be moved to a Web Server. Follow 1 and 2 above. For the third step, type:
$ play start
This will launch the application on the server, however it will still be listening on the server's localhost. Apache can be used as a proxy between a particular domain name (e.g starvote.cs.rice.edu) and the play! application. See this page.
To bring down the web server once it is live, cd to the web server directory and:
$ fuser -k 9000/tcp
$ rm RUNNING_PID
The Web Server hosts a web site that shows users all challenged ballots from an election, allowing them to insure that their ballots were handled correctly using the ballot ID on their receipt. The site also has a list of committed ballots where the voter may see that his committed ballot was counted, again using its ballot ID.
The server was written using the play framework which allowed us to use a combination of Java, Scala, HTML, CSS, and JavaScript. Documentation and tutorials for the framework may be found here
The model is comprised of only two classes - the CastBallot and ChallengedBallot classes. These classes are Entities, or templates for database elements allowing us to store both challenged and committed ballots as they are sent up to the server.
Cast ballots are primarily on the server to allow users to verify that their vote was counted, however the web server may not verify the integrity of that count because it does not have access to the private key required to decrypt the ballot
The cast ballot entity has three fields
- id: This is used by the database to search for an instance of the Entity
- ballotid: This is the identifier assigned to the ballot by the Votebox
- encryptedBallot: An encrypted form of the ballot is sent in case the ballot must later be decrypted in order to be downloaded for verification if a recount is requested or the integrity of the system is challenged.
Challenged ballots allow users to verify that their vote was counted accurately, this is done by sending a decrypted form of the ballot up to the server along with the encrypted ballot. The ballot can then be rendered into an html file using the web printer utility.
The challenged ballot entity has three fields
- id: This is used by the database to search for an instance of the Entity
- ballotid: This is the identifier assigned to the ballot by the Votebox
- decryptedBallot: The decrypted form of the ballot is sent since the web server does not have the keys to decrypt the ballot.
- encryptedBallot: An encrypted form of the ballot is sent in case the ballot must later be decrypted in order to be downloaded for verification if a recount is requested or the integrity of the system is challenged.
- precinct: The voter's precinct is sent so that the web server knows which ballot zip file to use to render the voter's ballot.
Play framework uses .scala.html files to create its web pages which are html files that use embedded scala (done by prefixing a command with the '@' symbol)
The main html file is called in scala at the top of all other pages, allowing all pages to have several elements in common. This file handles the navigation bar and the html divisions which encapsulate the style elements for various parts of each page.
The AuditServer class acts as the controller for this MVC, it handles almost all HTTP requests by processing and returning rendered pages. HTTP requests are routed to specified methods within the AuditServer class.
Admin pages exist on the site to allow administrators to clear the server's database without requiring access to the server directly. These administrators can log in at domain/login and once they are authenticated a session cookie allowing their continued access to the restricted areas of the site.
We have found that new versions of play are often incompatible with older versions due to a few configuration files, this can easily be fixed if one is using our code with a future version of play through this tutorial (or a more recent version of the tutorial which may be released on the Play website at a future date for the latest version of the framework.