Build a Social Network Server and a Client GUI that
(i) implement the functionality described in your Phase 1 submission,
(ii) are consistent with the general guidelines discussed here,
but
(iii) do not include code whose sole function is to enforce a security property or
resist attacks.
The distinction between baseline functionality and security properties
is not always clear cut.
Here are guidelines for deciding what functionality
your code in this phase should implement
(and, consequently, what functionality should not be
implemented until later phases).
-
For this phase, assume that all users are trustworthy.
That is, assume that (i) users initiate actions they should and
(ii) never initiate actions that they shouldn't.
(This is a bad assumption, and it will be revisited in subsequent phases.)
-
Client GUI should allow an identifier
(e.g., userid) to be input but this phase should
not expect or require a password to be input.
-
For this phase, do not use cryptography or cryptographic functions anywhere.
Consequently, (for this phase) no system component should generate or request
any form of secret key.
-
Implement post and view operations on posting boards and
(if your system supports them) regions.
These operations probably depend on a friends relation.
Feel free to implement that full functionality in this phase (even if it
seems to be a form of authorization).
-
Also as part of this phase (even it is seems to be a form of authorization),
provide the code and functionality for setting the friends relation
and for allowing users to change this relation.
-
Use persistent storage for saving
information (e.g., content postings and other relevant state)
that must be restored when execution
of the social network server is terminated and later restarted.
Employ a scheme that would allow the state for each different posting board
to be stored by different servers (i.e., by storing it in separate files,
separate databases, etc.).
Such a scheme will be useful for supporting scalability;
the scheme could also be useful if you decide that each user should be given
the power to select what server is trusted with that user's data.
Submission Procedure.
All submissions should be made through
CMS.
Submit the following files (at least) as part of a .zip:
-
TEAM.txt which contains the names (and net-ids) for all team members.
Also, for each team member give a 1 or 2 paragraph description of the tasks
this team member performed and the number of hours this required.
-
README.txt which contains
- The names and a description of the contents for the other files in the directory.
- Instructions for installing, compiling, and running your software on our
Windows system.
Expect the grader to spend approximately 10 minutes on this task, so try the process
yourself with a stopwatch to
check whether the grader might be able to fulfill your expectations.
- A tutorial that the grader can follow to run your software and observe
that it does what it should.
-
TESTPLAN.txt which explains the process you employed to test the system
you implemented and submitted for this phase.
TESTPLAN.txt should contain details about the kinds of test-cases you used
(or perhaps enumerate those test-cases) and it
should discuss the results of running those test-cases.
-
Source files that contain the source code needed to compile and run your system.
Grading Process.
Sign-up for a 1-hour system demo and group interview.
The sign-up sheet will be posted outside Upson 4115 at or before
11:25am on Friday 2/24.
Interviews will be scheduled starting on March 1, 2012
(location to be announced).
Your entire group must be present for the interview.
At the interview, a member of the course staff will:
-
Attempt to follow your instructions in README.txt
to "install" your system on a test machine.
-
Attempt to follow your instructions in README.txt
to operate your system and observe it working as it should.
-
Discuss design decisions and review the code for clarity and style.
-
Discuss the testing strategy and test results found in TESTPLAN.txt.