CreateSafe Project

Problem Statement

The project aims to provide authors (but not only) the possibility of an affordable way to protect their work while they produce it. The idea is simply of automate the process of certifying a copy of their work with a unique serial code and the date of protection. This way, any copyright infringement following from that date can be proved with the aid of the certified copy. Furthermore, the service will be available not only to authors, but any person that has creative work that needs to be protected as the website will accept non only PDF documents, but also images (whether they are a book cover or photographs or drawings).

On top of that, the project aimed to construct an API to allow third party applications to interact with the web application database in order to retrieve protected files and upload new ones. This requirement first identified on the first part of the project, was subsequently dropped, on agreement with the client, due to time constraints and lack of resources. This project website however, still contains some content on the research conducted on the design of the API, for sake of completeness and for possibility of further developments.

Requirements

Cease and Desist Letter:: email sent in order to urge somebody to stop infringing copyright and desist from doing it again in the future.

Functional Requirements
ID	Description	Category	Priority	Implemented
R1	The website shall allow storing and updating personal information.	Personal Account	Must
R2	The website shall allow storing and updating payment details.	Personal Account	Should
R3	The website shall be integrated with third party cloud services such as Dropbox and Google Drive in order to allow users easy upload of existing documents.	Uploading Documents	Could
R4	The website shall allow users to upload multiple files at the same time. (Drag & Drop functionality).	Uploading Documents	Must
R5	The website shall feedback the user on the uploading status (with a progress bar).	Uploading Documents	Must
R6	The system shall stamp each document with a unique serial code.	Uploading Documents	Must
R7	The website shall allow renaming of files once uploaded.	Uploading Documents	Could
R8	The website shall allow uploading and copyright protection for Video and Audio files.	Uploading Documents	Would
R9	The website shall allow payment through Paypal.	Payment	Must
R10	The website shall allow payment with major credit and debit cards.	Payment	Should
R11	The website shall allow searching and reordering of protected documents.	Managing Protected Documents	Should
R12	The website shall allow browsing of previously protected documents.	Managing Protected Documents	Must
R13	The website shall allow downloading, printing and emailing protected version of the document.	Managing Protected Documents	Should
R14	The website shall allow to send a Cease and Desist letter.	Managing Protected Documents	Must

Non-Functional Requirements
ID	Description	Category	Priority	Implemented
R15	The backend shall be implemented as a RESTful API in order to facilitate interfacing with the database.	API	Dropped
R16	Interfacing with the database should be made public through the publication of an API, keeping integrity and security a priority.	API	Dropped
R17	The system shall be able to create serial codes for millions of documents uploaded.	Reliability	Must
R18	The serial code must not be replicable from outside the system.	Security	Must
R19	The user flow shall count the minimum possible number of steps in the workflow of protecting files in order to keep the website simple to use.	Usability	Must
R20	The website shall have an updated and minimalistic GUI.	User Interface	Must

Use Cases

During the process of requirement analyses we came up with a list of Use Cases in order to indetify the interactions between different entities and the system.

Furthermore, the Use Cases helped us refine our requiremetns and understand how to model the system.

The Use Case diagram we created:

Use Case	Login
ID	UC1
Description	The User tries to login into the system
Primary Actor(s)	User
Secondary Actor(s)	None
Preconditions	None
Flow	The use case starts when the User is prompted to login. The User enters username and password. The system finds a matching entry in the database. The User is granted access to pages that require login.
Postconditions	User is logged in.
Alternative Flows	InvalidCredentials

Alternative Scenario	Login:InvalidCredentials
ID	UC1.1
Description	The User's credentials do not match any entry in the database.
Primary Actor(s)	User
Secondary Actor(s)	None
Preconditions	User has tried logging in with invalid credentials.
Flow	The alternative flow starts after step 2 of the Main Flow. The system does not find any matching entry in the database. The system feedbacks the User of not existing username or incorrect password. The User can reattempt login.
Postconditions	None
Alternative Flows	None

Use Case	Register
ID	UC2
Description	The User creates a new account.
Primary Actor(s)	User
Secondary Actor(s)	None
Preconditions	None
Flow	The use case starts when the User selects the ‘register’ option. The User enters account information (i.e. username, first name, last name, email, password). The system validates the input provided. The system stores new account into database. The User is granted access to pages that require login.
Postconditions	New User account is stored in the database and User is logged in.
Alternative Flows	InvalidField(s)

Alternative Scenario	Register:InvalidField(s)
ID	UC2.1
Description	The User has input invalid data in one or more fields, or the username/email exists already.
Primary Actor(s)	User
Secondary Actor(s)	None
Preconditions	User has tried creating a new account but has input invalid data in some field.
Flow	The alternative flow starts after step 3 of the Main Flow. The system finds an error in one or more fields or finds an entry in the database with same username/email. The system feedbacks the User of invalid field. The User can reattempt to register.
Postconditions	None
Alternative Flows	None

Use Case	UploadDocuments
ID	UC3a
Description	The User uploads documents to be protected.
Primary Actor(s)	User
Secondary Actor(s)	None
Preconditions	None
Flow	The use case starts when the User wants to protect a new document. The User uploads one or more documents: If the User Drag&Drop the files in the box, the system automatically uploads them. If the User selects ‘select your files’ the system open a file manager window for selecting files. The system feedbacks the user with a progress bar while the upload is progressing. The system validates the file(s) provided. The system stores file(s) in a temporary location.
Postconditions	Files uploaded are stored in a temporary location linked to User session.
Alternative Flows	InvalidFile
Error Flows	UploadingError

Alternative Scenario	UploadDocuments:InvalidFile
ID	UC3.1
Description	The User is not allowed to upload file with an invalid extension.
Primary Actor(s)	User
Secondary Actor(s)	None
Preconditions	User uploaded file with an invalid extension or a file over size constraint.
Flow	The alternative flow starts after step 4 of the Main Flow. The system feedbacks the User that one or more file have an invalid extension or is too heavy. The files are not uploaded. The system returns to the ‘upload’ window.
Postconditions	None
Alternative Flows	None

Error Scenario	UploadDocuments:UploadingError
ID	UC3.2
Description	The error occurs while uploading the file(s).
Primary Actor(s)	User
Secondary Actor(s)	None
Preconditions	User started uploading file(s).
Flow	The error flow can start at any time in the upload process. The system does not store the file and reports error to the User. The system logs the error message and trace. The system returns to the ‘upload’ window.

Use Case	UploadFromCloud
ID	UC3b
Description	The User uploads documents from Dropbox/Google Drive.
Primary Actor(s)	User
Secondary Actor(s)	None
Preconditions	None
Flow	The use case starts when the User wants to protect a new document and selects the Dropbox/Google Drive option. The system redirects to the login for the service selected. The User inserts credentials. The system redirects to the upload process and displays a list of files available in the cloud storage. The User selects one or more files. The system validates the file(s) selected. The system stores file(s) in a temporary location.
Postconditions	Files uploaded are stored in a temporary location linked to User session.
Alternative Flows	InvalidFile
Error Flows	UploadingError

Use Case	Pay
ID	UC4
Description	The User pays for the documents to be protected.
Primary Actor(s)	User
Secondary Actor(s)	Bank
Preconditions	User is logged in. User has uploaded some (at least one) files.
Flow	The use case starts after the User has uploaded files and logged in/registered. The system calculates total due for all items uploaded according to file extensions and feedbacks it to the User. The system asks User for confirmation (if User cancels Use Case terminates). If the User has saved payment details the system retrieves card details and autofills boxes. If the User has no card details saved, the User fills in boxes required for payment (i.e. cardholder name, card number, expiry date and CCV). The system sends details over User’s Bank for processing. The system generates unique serial code for each document uploaded and appends it to the document. The system stores the files in the User record. The system retrieves User’s email address and sends the User an email with list of uploaded files and serial codes and receipt of payment. The system returns to the User's personal area.
Postconditions	The payment is successful and the documents are certified and stored in the User record.
Alternative Flows	PaymentRefused.
Error Flows	PaymentError

Alternative Scenario	Pay:PaymentRefused
ID	UC4.1
Description	The Bank refuses the payment.
Primary Actor(s)	User
Secondary Actor(s)	Bank
Preconditions	User entered card details and system sent them to the Bank to be processed.
Flow	The alternative flow starts after step 4 of the Main Flow. The payment is refused by the Bank and the system receives an unsuccessful response. The system feedbacks the User of unsuccessful payment.
Postconditions	None
Alternative Flows	None

Error Scenario	Pay:PaymentError
ID	UC4.2
Description	The error occurs while processing the payment.
Primary Actor(s)	User
Secondary Actor(s)	Bank
Preconditions	User submitted payment.
Flow	The error flow can start at any time in the payment process. The system does not stamp the documents. The system feedbacks the User of the error encountered and logs error with date, time, user, action and message (and trace, if any).
Postconditions	Error is logged.

Use Case	UpdatePersonalDetails
ID	UC5
Description	The User updates personal details.
Primary Actor(s)	User
Secondary Actor(s)	None
Preconditions	User is logged in.
Flow	The use case starts after the User from the ‘personal area’ selects the ‘update personal details’ option. The system retrieves from database details for the User and autofills all boxes. The User selects field that wants to modify and submit the form. The system validates the field: If not valid the system feedbacks the User and the Use Case terminates. If the field is valid the system stores new value in the database and feedbacks the User of successful submission.
Postconditions	The User details are updated and stored in the database.
Alternative Flows	None

Use Case	UpdatePaymentDetails
ID	UC6
Description	The User updates payment details
Primary Actor(s)	User
Secondary Actor(s)	None
Preconditions	User is logged in.
Flow	The use case starts after the User from the ‘personal area’ selects the ‘update personal details’ option. The system retrieves from database details for the User card details (if any) and autofills all boxes. The User selects field that wants to modify and submit the form. The system validates the field: If not valid the system feedbacks the User and the Use Case terminates. If the field is valid the system stores new value in the database and feedbacks the User of successful submission.
Postconditions	The User details are updated and stored in the database.
Alternative Flows	None

Use Case	SendCeaseAndDesist
ID	UC7
Description	The User sends Cease and Desist letter to somebody who is infringing copyright of his/her work.
Primary Actor(s)	User
Secondary Actor(s)	None
Preconditions	User is logged in. User has at least one file uploaded and certified.
Flow	The use case starts after the User from the ‘personal area’ selects the ‘Cease and Desist’ option. The system retrieves from database list of protected documents for the User. The User selects relevant file from the list. The system fills in the form of the cease and desist letter with the file name and unique serial code, and other User details (name and email address). The User inputs the email address of the copyright offender. The User submits the form. The system sends email to the email address specified and returns to the User’s ‘personal area’.
Postconditions	The Cease and Desist letter is sent to the copyright offender.
Alternative Flows	None

Use Case	DownloadProtectedDocument
ID	UC8
Description	The User updates payment details.
Primary Actor(s)	User
Secondary Actor(s)	None
Preconditions	User is logged in.
Flow	The use case starts after the User from the ‘personal area’ selects the ‘my files’ option. The system retrieves from database list of files for the User. The User selects file to download. The system retrieves file from database and starts download.
Postconditions	The User downloads the protected file.
Alternative Flows	None

Use Case	AuthenticateUser
ID	UC9
Description	The External Application requests tokens to query API using the OAuth protocol.
Primary Actor(s)	External Application
Secondary Actor(s)	User
Preconditions	None
Flow	The use case starts when the external application sends a request to the CreateSafe API authorisation endpoint. The system redirects to the authorisation page. The User is prompted to login and to give access to the scope requested by the External application. The system checks that the client code is valid. (If not valid the system returns an invalid response and the Use Case terminates.) If User gives consent, the system redirects to the redirect URI provided by the External Application along with the authorisation code to the External Application. The External Application sends request for the access token to the CreateSafe API token endpoint. The system checks that the client ID and client secret match the authorisation code and returns access token and refresh token.
Postconditions	The External application receives tokens for querying the CreateSafe API.
Alternative Flows	None

Use Case	RequestListOfProtectedFiles
ID	UC10
Description	The External Application sends a request to retrieve the list of protected files for the User.
Primary Actor(s)	External Application
Secondary Actor(s)	None
Preconditions	The External Application has received a valid access token.
Flow	The use case starts when the external application sends a GET request to the CreateSafe API resource endpoint. The External Application sends the access token as part of the HTTP request header. The system checks that the access token is valid (if the access token is invalid the system returns an Invalid Token Error and the Use Case terminates). The system retrieves from the database the list of files for the User that the External Application has received authentication for and returns it to the External Application.
Postconditions	The External application retrieves the list of files for the User.
Alternative Flows	None

Use Case	RequestProtectedDocument
ID	UC11
Description	The External Application sends a request to retrieve a protected file.
Primary Actor(s)	External Application
Secondary Actor(s)	None
Preconditions	The External Application has received a valid access token.
Flow	The use case starts when the external application sends a GET request to the CreateSafe API resource endpoint. The External Application sends the access token as part of the HTTP request header. The system checks that the access token is valid (if the access token is invalid the system returns an Invalid Token Error and the Use Case terminates). The system retrieves the file from the database and returns it to the External Application (if the file requested does not exists the system returns an error response).
Postconditions	The External application retrieves the file.
Alternative Flows	None

Use Case	UploadNewDocument
ID	UC12
Description	The External Application sends a request to protect a new file.
Primary Actor(s)	External Application
Secondary Actor(s)	None
Preconditions	The External Application has received a valid access token.
Flow	The use case starts when the external application sends a POST request to the CreateSafe API resource endpoint. The External Application sends the access token as part of the HTTP request header. The system checks that the access token is valid (if the access token is invalid the system returns an Invalid Token Error and the Use Case terminates). The system generates unique serial code and appends it to the document uploaded. The system stores the file in the User's record. The system retrieves User’s email address and sends the User an email with the uploaded file details and its serial code. The system returns a successful response to the External Application.
Postconditions	The new file is protected and stored in the database.
Alternative Flows	None

Research

From the very beginning of the project it was clear that we would have to familiarise ourselves with web development techniques, hence, we spent the first two weeks learning and practising with HTML, CSS, Javascript and PHP. To do so we made use of many different resources available: books from the library, documentation online and Lynda.com online courses.

Front End

BootStrap

Bootstrap is the most popular HTML, CSS, and JS framework for developing responsive, mobile first projects on the web.

In order to design the front-end for the website we decided to make use of Bootstrap. The grid-system and the inherited web-responsiveness of it perfectly match our requirements for the website being mobile optimized.

Despite it already provides a clean and appealing style, we plan to override some of it in order to adapt it to our client's requirements and personalise it.

Dropzone.js

DropzoneJS is an open source library that provides drag’n’drop file uploads with image previews.

Dropzone is an open-source library written in Javascript, HTML and CSS that provides a GUI for the upload of files. It supports both Drag&Drop functionalities and a file-manager window selection of files. Furthermore, it provides a graphic feedback of the files uploaded and image previews.

Back End

Symfony 2

Symfony is a set of PHP Components, a Web Application framework, a Philosophy, and a Community — all working together in harmony.

In order to facilitate the development of the back-end we decided to make use of one of the most used open-source PHP frameworks available online. Out of many frameworks available, (both full-stack like Laravel or CakePHP and micro-frameworks such as Slim and Silex), we decided to opt for Symfony basing our decision on a list of characteristics we deemed fundamental for our project:

extensive documentation available on the website, piled during all years of its existence that also guarantees a prolific community and stability.
availability of third-party bundles that we could make use of, in order to satisfy the requirements outlined in the first phases of the project (refer to the "Requirements" section).
the high emphasis symfony puts into testing. In particular the perfect integration with PHPUnit that could ease the testing of our code.

Finally, Symfony naturally integrates the Model-View-Controller (MVC) architecture in its structure.

Third-Party Bundles.

One of the most valuable properties about Symfony is the substantial list of third-party components available to use in order to avoid having to write from scratch code that has already been written and thoroughly tested.

Symfony Standard Edition comes with a list of useful bundles already integrated that we decided to stick with:

Twig:: Twig: a template engine for PHP. It is powered by a flexible lexer and parser that provides conciseness and full featured syntax.
SwiftMailer:: a bundle that offers an Object Oriented approach for sending emails while providing optional additional features.
Doctrine:: an Object-Relational Mapping (ORM) library that facilitates integration with the mySQL database.

Furthermore, after careful research we decided to make use of these additional components:

OneupUploaderBundle:: provides the backend for the uploading of files using the Dropzone Javascript library as front-end. Among its features, it provides the possibility of using an Orphanage for handling of files from anonymous users.
FOSRestBundle:: it provides several tools for building RESTful APIs. We are going to make use of this component when creating the API for the website in order to allow third-party applications to interface with the CreateSafe resources.
FOSAuthServerBundle:: bundle that provides a security layer in dealings with resources. In particular it helps integrating the OAuth 2 protocol for grating access to the User’s resources.
HWIOAuthBundle:: supports the OAuth protocol from the client side. We plan to use this to access services like Google Drive and Dropbox and to test our own API.