SE 3316A代做、代写Web Technologies、Java编程设计调试、Java语言代做

日期：2019-11-28 10:24

SE 3316A Web Technologies Lab #5: Due Sunday, Dec. 1, 11:55 pm

Develop a music review site where users can submit reviews of musical performances. Functionality is

similar to IMDb.

Deadlines:

Submission deadline: Sunday, Dec. 1, 11:55 pm. Submission closes on Wed. Dec 4th 11:55pm.

Demonstration deadline (firm): Friday, Dec 13, 5pm.

Evaluation

1. 10% penalty per day for submissions after Dec. 1th. Submissions will not be accepted after Wed.

Dec. 4th.

2. All demonstrated must be completed before Friday Dec. 13th.

3. Any test item that is checked must pass the test without any conditions. During the demonstration,

you may request part marks by providing a written request that states what test items fail and the

impact that will have on the functionality of that item. E.g. If test items 3.f.i, 3.f.ii and 3.f.iv passes,

but 3.f.iii fails, what impact would that have on functionality of 3.f?

Revision History

1. Added a workaround for email verification (1.e): FAQ#3 - Nov. 16

2. Removed playlist functionality from requirements: 3.g-3.m - Nov 16

3. Simplified DMCA functionality and added clarifications: 6.c - Nov 16

4. Added a Suggested work-flow (last section). Nov. 17

5. Added point values and ??to indicate features that are relatively easy. Nov 17

6. Corrected the total point values for #4 and overall total. Nov 21

7. Made 3rd party authentication a bonus mark: 1.b - Nov 25

Objectives:

A. Apply knowledge of server-side and client-side scripting and modern web application frameworks to

create a complex web application.

B. Expose major functionality of the application via a ReSTfull web API.

C. Develop a client application using the above API.

D. Incorporate 3rd party services to a web application.

E. Implement an authentication protocol and provide different levels of functionality to authenticated

vs. unauthenticated users.

F. Implement a client application that works on both mobile as well as a variety of desktop browsers

and presents a user interface that scales appropriately.

G. Develop applications that are resistant to malicious exploitation.

H. Create a security and privacy policy that is publicly accessible.

I. Create a DMCA notice & takedown policy that is publicly accessible.

J. Provide a DMCA takedown procedure and tools for the site administrator:

a. Log requests, notices, and disputes.

b. Send a takedown notice for any DMCA requests received and disable display of alleged

copyright violations.

You must use Angular v8 as the front-end framework and Node.js for back-end implementation. You may

use other libraries and services to implement authentication. You must disclose all code that you copy from

any source if that code is contained in your submission on Owl. This disclosure must include a link to the

source as well as a summary of what parts are copied. This disclosure does not apply to any libraries that

you use if that library is not part of your git repository (e.g. code in ‘node_modules’ directory).

Submission Instructions:

Please carefully read the instructions and strictly follow them. Your grade depends on it.

1. Ensure that your repository is named “se3316-xxx-lab5”(all lowercase) where “xxx” is your Western

email ID (without @uwo.ca part).

2. Use a proper “.gitignore” file so that only the files that you edit are in your repository.

3. Copy the output of command “git log” and paste that onto the submission page (Assignments

section) on Owl.

4. Download your repository as a zip file from Github and submit as an attachment. Please do not zip

the folder on your computer as it contains a large amount of extraneous files. Ensure that libraries,

data files, intermediate files or backup folders are not included in the zip file.

5. Ensure that your Github repository is shared with TAs.

6. Print the test plan and complete it including the last commit ID, commit date/time and total points.

7. Demonstrate your lab before the demonstration deadline. You must submit a completed and signed

copy of the test plan to the TA before the demonstration starts. If the completed and signed test

plan is not ready at the start of demonstration, you will be asked to reschedule the demo.

Penalties will apply for not following the naming convention or any of the submission steps.

Schedule:

You may complete it at home. TAs will be available in 3C+ 4435/4440 during lab hours (Mondays

8:30am-10:30am, Tuesdays 8:30am-10:30am and 10:30am-12:30am) to answer any questions that you

may have.

Description

Develop a web application for a music review site that allows browsing reviews, creating, editing and saving

new reviews, creating and managing playlists, sharing playlists with other users and commenting public

playlists.

Use of Node.js and Angular v8 is required. Other technologies may include Mongodb and Express or any

alternatives that suit you better.

In case of any ambiguities, conflicting or unclear requirements, you are free to make a choice that is (a)

sensible, (b) minimize your effort and (c) in keeping with the spirit of the application. However, you are

required to document all such decisions using git comments.

This document may be revised to improve readability or to remove ambiguous, conflicting or unclear

requirements. Please pay attention to the revision statement at the top of this document.

Requirements (90 points + 4 bonus points)

1. Authentication method: {total 12 points + 4 bonus points}

a. Local authentication mechanism which uses email as the username and require a password.

{4 points} ??

b. One external authentication mechanism (e.g. Google, Apple, Facebook etc) that

authenticates via a third-party such as Google, Facebook etc. {4 bonus points}

c. Input validation for email (proper format). {2 points} ??

d. Local passwords stored using the most secure method available (e.g. Argon2). {1 point} ??

e. Verification of of email (see References). {3 points}

f. If the account is marked as deactivated, show a message asking to contact the site

administrator and not allow logging in. {2 points}

2. Limited functionality for unauthenticated users. {total 24 points}

a. Start page showing application name, a short “about” blurb that says what the site offers, and

login button. {2 points}??

b. List of songs (up to 10) ordered by popularity (e.g. number of users who reviewed that song

or average rating). Any sensible criteria of popularity is acceptable. {4 points}??

c. Ability to search songs based on keywords. {6 points}??

d. Keywords are matched with all attributes of the item (see ID3v1 below). {2 points} ??

e. Keywords are soft-matched (e.g ignore differences in case, white-space, minor spelling

variations). {2 points}

f. Ability to view all information on a song by clicking or expanding (shows all attributes, most

recent review, the number of reviews and the average rating. {4 points}??

g. Ability to view all reviews for a song: {2 points}

h. Each review shows the rating, the review and reviewer’s username: {2 points}

3. Additional functionality for authenticated users: {total 18 points}

a. Add a review to a song. {4 points} ??

b. Add a rating (1-5, star etc) to reviews created by the user. {2 points} ??

c. Add a new song to the site. {4 points}??

d. Support storing all ID3v1

1 attributes for each new song. {4 points}??

e. Enforce required attributes “title” and “artist” when adding a new song. {2 points}

f. Add a review while adding a new song if necessary. {2 points}

g. Create a playlist of songs. Each playlist must have a title and an optional description.

h. Within search results, add songs to a playlist.

i. Create a new playlist within search results.

j. Edit the title and description of a playlist by its owner.

k. Add or remove songs from a playlist by its owner.

l. Set the visibility setting of a playlist to “private” (default) or “public” by owner. {6 points}

m. Playlists marked as “private” do not show up on search results for others.

4. Site manager functionality related to site maintenance: {total 10 points}

a. Special user with site manager access. {4 points}??

b. Ability to grant site manager privilege to one or more existing users: {2 points}

a. Ability to add/modify/delete songs and playlists.

c. Ability to mark a song as hidden and clear the “hidden” flag if set: {2 points}

d. Ability to mark a user as “deactivated” and mark as “active” if deactivated: {2 points}

5. Web service API: {total 14 points}

a. Provide an API that has at least four nouns (URLs) and at least 8 separate noun+ HTTP verb

combinations. Must have at least two nouns that support two or more verbs. {8 points} ??

b. Build your application using this API. {6 points} ??

6. Site manager functionality related to copyright enforcement: {total 12 points}

a. Create a security and privacy policy that is publicly accessible. {2 points} ??

b. Create a DMCA notice & takedown policy that is publicly accessible. {2 points} ??

c. Provide a DMCA takedown procedure and tools for the site administrator: {total 8 points}

i. Document to describe the workflow and usage of tools. {2 points} ??

ii. Tools to log requests, notices, and disputes. E.g. Set-up properties for storing “date

request received”, “date notice sent”, “date dispute received” with each song and

provide an interface to set these properties. {2 points}

iii. Tools to disable display of songs with alleged copyright violations. {2 points}

iv. Tools to restore any contested songs. {2 points}

7. Usability and code quality: {up to -30 points}

a. Resistant to HTML and JavaScript injection attacks, {up to -2 point}

b. Able to handle user input in any language. {up to -2 point}

c. Usability of the application on multiple browsers and form factors. {up to -2 point}

d. Modular code that is easily extensible and maintainable. {up to -2 point}

i. E.g. Changes to operational parameters such as server names, port numbers etc

should not cause changes in code.

e. Avoid code duplication. {up to -2 point}

1 See https://en.wikipedia.org/wiki/ID3

i. E.g. Full URLs that are duplicated in calls to ReST api

f. Avoid hard-coded literals in code. {up to -4 points}

i. E.g. Hard-coded port numbers, URLS

g. Frequent git commits with meaningful commit messages. {up to -10 points}

h. Sufficient and meaningful comments in code. {up to -2 points}

i. Proper precautions in saving user information. {up to -4 points}

References

1. Authentication library: http://www.passportjs.org/ or https://auth0.com/

2. Email verification: https://www.npmjs.com/package/email-verification

3. Salted Password Hashing - Doing it Right: https://crackstation.net/hashing-security.htm

4. Responsive design using Angular - https://material.angular.io/

5. DMCA Demystified: http://www.sfwa.org/2013/03/the-dmca-takedown-notice-demystified/

6. GitHub DMCA policy: https://help.github.com/articles/dmca-takedown-policy/

7. Angular Security; https://angular.io/guide/security

Resources

1. Firebase is a good option which provides authentication and database: https://firebase.google.com

2. JWT is the recommended method for implementing authentication and protected routes:

a. Main site: https://jwt.io

b. Good tutorial: https://github.com/dwyl/learn-json-web-tokens

3. Copyright enforcement functionality: See slides 16-19 of “social issues” unit

FAQ

1. You will need a developer account for the third-party authentication. Only one external provider is

needed.

2. Questions about item 6 (copyright enforcement): Please look at the test plan. You may device and

implement any mechanism to satisfy the tests. As long as it is part of the application and satisfies

the test, it will be accepted. No automation is needed. E.g. the site administrator may receive a

notice via email, which the administrator may log manually via the application.

3. Email verification (1.e) requires the ability to send emails out, which is getting harder due to stricter

anti-spam controls implemented by major service providers. Because of this, you may implement a

mock-up of the verification step as follows:

a. User enters an email address to create a new account.

b. An email is crafted that includes a unique link that the user is required to click in order to

verify the email address.

c. Instead of sending this email to the address that the user provided, it is shown on the client.

d. When user visits the unique link (copy+paste to another browser window), the address is

verified.

Suggested Workflow

Following is a suggested workflow to plan the implementation of this lab. Some design suggestions are

provided only for information and you are not required to follow them.

1. Read the Requirements section several times until you develop a mental picture of what the

application does.

2. Read the ID3v1 spec and design a JSON array to hold required attributes for ID3v1 as well as other

attributes that your program may need (e.g. submitted-by, submitted-on, number of ratings,

average rating etc).

3. Design a Database structure. E.g. for mongoDB, separate collections for song, review, and user as

the tables. ObjectID of each record in each collection will be used as the primary key for each table.

4. Sketch a preliminary API that provides the basic functionality. Following is an example design.

a. Designate separate API prefixes for non-authenticated, regular user and admin categories.

E.g. All paths in “/api/secure/” require authentication as a regular user. Paths in

“/api/admin/” require admin privileges. Paths in “/api/open/” does not require

authentication.

b. PUT /api/secure/song/ - save the JSON array for a song in the database and return the ID.

c. POST /api/secure/song/:id - update the record of the given song ID with JSON array of

properties sent in the body.

d. GET /api/open/song - return a list of 10 songs ordered by average rating. Optionally, you may

pass a query parameter to indicate the number of results to return.

e. GET /api/open/search - return a list of songs matching the search criteria provided as query

parameters.

f. GET /api/open/reviews/:id - return all reviews for a given song ID.

g. PUT /api/secure/add-review/:id - Create a new review for the song with the given ID based

on JSON array provided in the body.

h. POST /api/admin/copyright/:id - Set or update copyright violation attributes for a given song

ID. JSON array with new values is provided in the body.

i. GET /api/admin/copyright - Return all songs which are marked as copyright violations.

j. POST /api/admin/deactivate/:id - Set or clear “account deactivated” flag for a given user.

5. Review steps 1-4 and re-examine each design decision to verify that it provides the foundation for

your current understanding of the requirements.

6. Implement access control logic first for /api/secure and /api/admin.

a. Implement all the routes first. Don’t need to implement actual functionality. E.g. log message

on console to verify that it receives the request.

b. Implement access control for one route in /api/secure. Each request must present a JWT and

this token must be verified by the back-end functionality. See slides for “router.use()” for

implementing such common functionality.

c. You may start with a pre-generated JWT and use a ReST client (E.g. Insomnia) to test the

functionality.

d. Implement access control in all remaining routes and ensure that code for access control is

not duplicated.

7. Implement back-end functionality for 4.b, 4.c and 4.d and test it with a ReST client.

8. Implement front-end Angular components for 4.b, 4.c and 4.d and test it.