SE 3316A Web Technologies Lab #5: Due Friday, Dec. 4, 11:55 pm
Deadlines:
• Submission deadline: Friday, Dec. 4, 11:55 pm. Submission closes on Wed. Dec 4th 11:55pm.
• Demonstration deadline: Wednesday, Dec 16, 5pm.
Evaluation
• Up to 10 marks and up to 10 bonus marks (total of 20) for evidence of credible actions to finish by the due date. Such actions are measured by functionality completed each week (as indicated by Git commits) as well as submission by due date.
• 10% penalty per day for submissions after Dec. 4th. Submissions will not be accepted after Wed. Dec. 9th.
• All demonstrations must be completed before Wednesday Dec. 16th.
• A test plan with detailed tests will be provided. 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
• Corrected typo in the due date on title – Nov. 16
• Added FAQ items 5, 6 and 7 – Nov. 16
• Revised demonstration criteria – Nov. 17
• Revised 4.a to include display of lists and added 4.b to display timetable for a list – Nov. 18
• Revised minimum size in 3.d to 4 characters instead of 5 – Nov 19
• Revised input sanitation requirements by adding details – Nov 20
Objectives:
• Apply knowledge of server-side and client-side scripting and modern web application frameworks to create a complex web application.
应用服务器端和客户端脚本以及现代 Web 应用程序框架的知识来创建复杂的 Web 应用程序。
• Expose major functionality of the application via a ReSTfull web API.
通过 ReSTfull Web API 公开应用程序的主要功能。
• Develop a client application using Angular with the above API.
用 Angular
• Incorporate 3rd party services to a web application.
将第三方服务整合到 Web 应用程序中。
• Implement an authentication protocol and provide different levels of functionality to authenticated vs. unauthenticated users.
实施身份验证协议，并向经过身份验证的用户和未经身份验证的用户提供不同级别的功能。 登陆了的人和没登录的人能干的东西不一样。
• 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.
实施可在移动设备以及各种桌面浏览器上运行的客户端应用程序，并提供适当缩放的用户界 面。
• Develop applications that are resistant to malicious exploitation.
开发能够抵抗恶意利用的应用程序。
• Create a security and privacy policy that is publicly accessible.
创建可公开访问的安全和隐私策略。
• Create a DMCA notice & takedown policy that is publicly accessible.
创建可公开访问的DMCA通知和删除策略。
• Provide a DMCA takedown procedure and tools for the site administrator:
为网站管理员提供DMCA移除程序和工具：
• Log requests, notices, and disputes.
记录请求，通知，和纠纷。
• Send a takedown notice for any DMCA requests received and disable display of alleged copyright violations.
针对收到的所有DMCA请求发送删除通知，并禁止显示涉嫌侵犯版权的内容。
You must use Angular v10 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 source 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).
必须用Angular v10来做前端框架，并用Node.js做后端。可以使用其他库和服务来实现身份验证。如果在Owl上提交的内容中包含从任何其他资源复制的代码，则必须公开该源代码。 此公开内容必须包括到源的链接以及要复制的部分的摘要。 如果该库不是你的git信息库中的一部分，则此公开不适用于你使用的任何库（例如，“ node_modules”目录中的代码）。
Submission Instructions:
Please carefully read the instructions and strictly follow them. Your grade depends on it.
• Ensure that your repository is named “se3316-xxx-lab5”(all lowercase) where “xxx” is your Western email ID (without @uwo.ca part).
• Use a proper “.gitignore” file so that only the files that you edit are in your repository.
• Copy the output of command “git log” and paste that onto the submission page (Assignments section) on Owl.
• 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.
• Ensure that your Github repository is shared with TAs.
• New: Submit a completed test plan in PDF format including the last commit ID, commit date/time and total points.
• Demonstrate your lab (on a public URL) before the demonstration deadline. You may set up the public URL after submission on Owl. As long as the changes only involve deployment issues, it is acceptable. You must also submit a completed and signed copy of the test plan on Owl before the demonstration starts. If the completed and signed test plan was not submitted before the demonstration, you will be asked to reschedule the demo.
Penalties will apply for not following the naming convention or any of the submission steps
Description
Develop a web application for searching Western timetable that provides the functionality of current online timetable at a minimum. In addition this web application must also provide the ability to create an account, save and edit lists of courses for logged in users, ability to publish these lists as well as the ability to add comments/ratings to individual courses.
开发一个用于搜索western timetable的Web应用程序，该应用程序至少提供当前在线时间表的功能。 另外，该Web应用程序还必须具有创建帐户，保存和编辑已登录用户的课程列表的功能，发布这些列表的功能以及向单个课程添加评论/评分的功能。
Use of Node.js and Angular v10 is required. Other technologies may include Mongodb and Express or any alternatives that suit you better.
需要用到Node.js和Angular v10。其他技术可能包括Mongodb和Express或任何更适合你的替代方法。
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. It is strongly advised to discuss such assumptions on the “Labs” channel on Teams if you are not sure. You are also 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.
Design Tip
Keep the number balls you juggle at one time to about 5 so that you are not overwhelmed by the complexity. E.g. Keep the number of objects/concepts/modules that you have to grapple at one time to 5. At the highest level, you may want to imagine about 5 components that make up the full application. If these components as well as interactions among them work as intended, then your application should work as intended. You may call that the architecture of your application. Then think about the design of each component and apply the same principle.
Complexity of an application is not just the number of components, but also the number of interactions between these components. A system with 5 components where each component interacts with every other component is more complex than a system with 10 components where each component only interacts with two other components although they both have the same number of interactions.
Requirements and Rubric (100 points + 10 bonus points)
Search terms refer to those used on the Western the online timetable. A “course ID” is defined as the combination of the subject field and the 4-digit part of the catalog_nbr field. Items marked with 🍰 indicates features that are relatively easier.
搜索词是指在western online timetable上使用的那些词。“course ID”是指由subject加上一个四位的catalog_nbr组成的字符串。
• Show evidence of credible actions to finish by the due date. Such actions are measured by functionality completed each week (as indicated by Git commits) as well as submission by due date. {total 10 points + 10 bonus points}
在交作业日期之前的每一天都要一步一步的上传 code
• Authentication method: {total 10 points}身份验证方法
• Provide a local authentication mechanism (create an account with an email, a password and a name, update password). {4 points}
提供本地身份验证机制（创建一个包含电子邮件， 密码和名称的帐户，并且能更新密码）。
• One external authentication mechanism (e.g. Google, Apple, Facebook etc) that authenticates via a third-party such as Google, Facebook etc. {2 points}
一种通过第三方 （例如 Google，Facebook 等）进行身份验证的外部身份验证机制（例如 Google， Apple，Facebook 等）
• Input validation for email (proper format). {1 points} 🍰
输入电子邮箱验证(正确格式)
• Verification of email (see References). {2 points}邮箱验证
教程：https://www.npmjs.com/package/email-verification
• If the account is marked as deactivated, show a message asking to contact the site administrator and not allow logging in. {1 point}
如果该帐户被标记为已停用，则显示一条 消息，要求与站点管理员联系，并且不允许登录。
• Limited functionality for unauthenticated users. {total 25 points}
对于没有登陆的用户来说可以实现的有限功能
• Start page showing application name, a short “about” blurb that says what the site offers, and a login mechanism. {2 points} 🍰
起始页面，显示应用程序名称，简短的介绍说网站能干什么和登陆的机制
• Interface for searching courses based on any combination of subject (e.g. “SE” or “ECE”) , course number (e.g. 3316) or course number and a case-insensitive suffix (e.g. 3316A, 3316a, 3375B or 3375b etc). Search results must show subject, catalog_nbr, className , class_section, ssr_component and timetable data at a glance. {8 points}
用于根据subject（例如“ SE”或“ ECE”），课程号（例如 3316）或课程号和不区分大小 写的后缀（例如 3316A，3316a，3375B 或 3375b 等）的任意组合搜索课程的界面。搜 索结果必须一目了然地显示 subject，catalog_nbr，className，class_section， ssr_component 和时间表数据。 搜索功能同 lab3。
• Expand each search result to view all remaining information of each course. {2 points} 🍰
展开每个搜索结果以查看每个课程的所有剩余信息
• Ability to search courses based on keywords where keywords are at least 4 characters long and matched with any substring within catalog_nbr or className fields. {4 points}
能够根据关键字搜索课程，其中关键字的长度至少为 4 个字符，并且与 catalog_nbr 或 className 字段中的任何子字符串匹配。
• Keywords are soft-matched (e.g ignore white-space, minor spelling variations or mistakes). {2 points}
关键字是软匹配的（例如，忽略空格，较小的拼写变化或错误）
• List of public course lists (up to 10) ordered by last modified date and showing name, creator and number of courses in the list. {3 points} 🍰
课程列表（最多 10 个 有 10 个限制），按最后修改日期排序，并在列表中显示课程的 名称，创建者和数量。
• Ability to expand each course list to show the description and the list course IDs. {1 point} 🍰
每个课程列表可以展开看到课程的描述和课程的 id
• Ability to retrieve and display the timetable data for all the courses in a public course list. {3 points}
能够检索和显示公共课程列表中所有课程的时间表数据
• Additional functionality for authenticated users: {total 25 points}
对于登陆的用户来说可以实现的更多功能
• Create up to 20 named lists of courses that contain a unique name (required), a description (optional), a list of subject and catalog_nbr pairs (required) and a visibility flag of public or private with the default set to private and show all lists. {8 points}
可以创建最多 20 个命名了的课程列表，包括: 一个独一无二的名字(必填)，一个描述(可选，非必填)，一个由subject+catalob_nbr的字符串组成的列表(list)(必填)，以及一个显示public或private的可见性标志，默认设置为private并显示所有列表(list)。
• Clicking on a list shows the timetable for all the courses in the list. {2 points}
点击其中一个 list 可以显示这个列表所有课程的课程表（图表）
• Edit all aspects of an existing course list and record the last edited time. {4 points} 🍰
可以编辑现有课程列表的各个方面并记录上次编辑的时间
• Delete a course list. {3 points} 🍰
可以删除一个课程列表
• Add a review to a course. (defined by a given course ID). {6 points}
可以给课程添加评论。 （由给定的课程ID定义）。
• Enforce all required attributes when creating or editing a course list. {2 points} 🍰
在创建或编辑课程列表时，强制执行所有必需的属性
• Administrator functionality related to site maintenance: {total 10 points}
与站点维护相关的管理员功能：
• Special user with administrator access. {4 points}
具有管理员访问权限的特殊用户
• Ability to grant site manager privilege to one or more existing users: {2 points} 🍰
能够向一个或多个现有用户授予站点管理员特权
• Ability to mark a course review as hidden and clear the “hidden” flag if set: {2 points} 🍰
能够将课程评论(course review)标记为隐藏，并清除“hidden”标志（如果已设置）
• Ability to mark a user as “deactivated” and mark as “active” if deactivated: {2 points} 🍰
能够将用户标记为“deactivated”(停用)，并在停用时标记为“active”(活动)
• Web service API: {total 10 points}
• Revise the API developed for lab 3 as necessary to provide required functionality. {6 points}
根据需要修改实验3时开发的API，以提供所需的功能
• Build your application using this API. {4 points} 🍰
使用此API构建你的应用程序
• Administrator functionality related to copyright enforcement: {total 10 points}
与版权实施有关的管理员功能
• Create a security and privacy policy that is publicly accessible. {2 points} 🍰
创建可公开访问的安全和隐私策略。
• Create an “acceptable use policy” (AUP) that is publicly accessible. {2 points} 🍰
创建可公开访问的“可接受的使用策略”（AUP）。
• Create a DMCA notice & takedown policy that is publicly accessible. {2 points} 🍰
创建可公开访问的DMCA通知和删除策略。
• Provide a DMCA takedown procedure and tools for the administrator: {total 4 points}
为管理员提供DMCA移除程序和工具
• Document to describe the workflow and usage of tools. {1 point} 🍰
描述工具的工作流程和用法的文档
• Tools to log requests, notices, and disputes. E.g. Set-up properties for storing “date request received”, “date notice sent”, “date dispute received” for each course review and provide an interface to set these properties. {1 point}
记录请求，通知和争议的工具。 例如: 用于存储每个课程评论的“接收到请求的日期”，“发送通知的日期”，“接收日期的争议”的设置属性，并提供用于设置这些属性的界面。
• Tools to hide reviews with alleged copyright or AUP violations. {1 point}
隐藏涉嫌侵犯版权或违反AUP的评论的工具。
• Tools to restore displaying of any contested reviews. {1 point}
恢复所有有争议评论的显示的工具。
• Usability, code quality and other non-functional requirements:
可用性，代码质量和其他非功能性要求
• Insufficient input sanitization including not limiting range (where applicable), length and content (where applicable) as well as interpreting any user input as HTML, CSS or JavaScript, to safeguard against injection attacks. {up to -10 points}
输入部分处理的不足，包括不限制范围、长度和内容(在适用情况下)，以及将任何用户输入解释为HTML, CSS或JavaScript，以防止注入攻击。
• Not using JWT for any authorization task. {up to -10 points}
没有使用JWT来完成任何授权任务
• Not able to handle any user input in any language. {up to -5 points}
无法处理任何语言的任何用户输入，即应该能处理任何语言的用户输入
• Usability issues of the application on multiple browsers and form factors. {up to -5 points}
应用程序在多个浏览器和外形上的可用性问题
• Lack of modular code that is easily extensible and maintainable. {up to -5 points}
缺乏易于扩展和维护的模块化代码
• E.g. Changes to operational parameters such as server names, port numbers etc should not cause changes in code.
例如: 更改服务器名称，端口号等操作参数不应导致代码更改。
• Presence of code duplication. {up to -5 point}
存在代码重复
• E.g. Full URLs that are duplicated in calls to ReST api, copy/paste of code blocks that are mostly similar etc.
例如：完整的URL，在对ReST api的调用中重复，复制/粘贴大多数相似的代码块等。
• Presence of hard-coded literals in code. {up to -5 points}
硬编码文字存在于代码中
• E.g. Hard-coded port numbers, URLs
例如：硬编码的端口号，URL
• Insufficient git commits (<20) with meaningful commit messages. {up to -20 points}
少于20个有意义的git commits
• Lack of sufficient and meaningful comments in code. {up to -5 points}
代码中缺少足够有意义的注释
• Not exercising proper precautions in saving user information. {up to -5 points}
在保存用户信息时未采取适当的防范措施
• Use of sufficiently strong hash algorithms such as BCrypt or Argon2, use of a salt.
使用足够强大的哈希算法，例如BCrypt或Argon2。
• Code management with Git {up to -30 points}
• Less than 20 commits that are meaningful, no meaningful commit messages, not using a proper .gitignore file to ignore external dependencies, not using Git pull to deploy code to server.
少于20个有意义的commit，没有意义的commit信息，没有使用一个适当的gitignore文件忽略外部依赖
• Logistics {up to -15 points}
• Repository name not in required format, no zip file (not graded), code is not attached as a zip file or it contains content that is not in the Git repository or is missing content that is in the repository, test plan not in PDF format.
References
• Authentication library: http://www.passportjs.org/ or https://auth0.com/
• Email verification: https://www.npmjs.com/package/email-verification
• Salted Password Hashing - Doing it Right: https://crackstation.net/hashing-security.htm
• Responsive design using Angular - https://material.angular.io/
• DMCA Demystified: http://www.sfwa.org/2013/03/the-dmca-takedown-notice-demystified/
• GitHub DMCA policy: https://help.github.com/articles/dmca-takedown-policy/
• Angular Security; https://angular.io/guide/security
Resources
• Firebase is a good option which provides authentication and database: https://firebase.google.com. Firebase UI, SDK or equivalent library/framework is acceptable for implementing a login mechanism.
• JWT is the required method for implementing authorization and protected routes:
• Main site: https://jwt.io
• Good tutorial: https://github.com/dwyl/learn-json-web-tokens
• Copyright enforcement functionality: See slides 16-19 of “social issues” unit
FAQ
• You will need a developer account for third-party authentication. Only one external provider is needed.
• 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. Assume that the site administrator may receive copyright/abuse claims via email. The administrator only needs to be able to log such requests via the application.
• 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:
• User enters an email address to create a new account.
• An email is crafted that includes a unique link (eg. generated from a hash of user information) that the user is required to click in order to verify the email address.
• Instead of sending this email to the address that the user provided, it is shown on the client.
• When a user visits the unique link (copy+paste to another browser window), the address is verified.
• Soft-matching strings using the Dice coefficient: https://www.npmjs.com/package/string-similarity
• You may use any database.
• You may redesign the back-end API as necessary.
• A mechanism to register users is required. See 2.a in requirements.
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.
• Read the Requirements section several times until you develop a mental picture of what the application does.
• Design a Database structure for the selected database.
• Revise the API designed in lab 3 to provide basic functionality. It is a good idea to 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.
• Review steps 1-3 and re-examine each design decision to verify that it provides the foundation for your current understanding of the requirements.
• Implement access control logic first for /api/secure and /api/admin.
• 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.
• 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.
• You may start with a pre-generated JWT and use a ReST client (E.g. Insomnia) to test the functionality.
• Implement access control in all remaining routes and ensure that code for access control is not duplicated.
• Implement back-end functionality for a particular feature or a group of connected features and test it with a ReST client.
• Implement front-end Angular components that use the back-end functionality developed above.
• Keep dependencies between modules to a simple tree-like structure.