web application deveopment

Cardiff School of Computer Science and Informatics

Coursework Assessment Pro-forma

Module Code: CMT120 Module Title: Fundamentals of Programming Lecturers: Federico Liberatore, Martin Chorley,

Natasha Edwards Assessment Title: Web Application Development Date Set: 25th November 2021 Submission date and Time: 27th January 2022 at 9:30AM Return Date: 24th February 2022

This assignment is worth 60% of the total marks available for this module. If coursework is submitted late (and where there are no extenuating circumstances):

1. If the assessment is submitted no later than 24 hours after the deadline, the mark for the assessment will be capped at the minimum pass mark;

2. If the assessment is submitted more than 24 hours after the deadline, a mark of 0 will be given for the assessment.

Your submission must include the official Coursework Submission Cover sheet, which can be found here: https://docs.cs.cf.ac.uk/downloads/coursework/Coversheet.pdf

Submission Instructions

Your coursework should be submitted as follows: Description File Type File Name Location (1) Cover sheet .pdf file STUDENT_NO_cover.pdf* Learning Central (2) git repository on COMSC’s GitLab server

complete source code of website

Repository name should be: STUDENT_NO_cmt120_cw2*

https: //git.cardiff.ac.uk/

(3) report on your website’s quality, usability and security

.pdf file STUDENT_NO_report.pdf * Learning Central

(4) Coursework submission details form

online form submission

’CMT120 - CW 2 - Submission Details Form (21-22)’

link will be posted in ’Assessment’ area on Learning Central

* Replace STUDENT_NO with with your Student Number without the leading ’c’, e.g. 1234567, and not c1234567

More specifically:

• For item (2):

– submit (push) your complete source code to COSMC’s GitLab server, and share your repository with Natasha Edwards and Martin Chorley as follows:

* On the Project page, go to: Project Information > Members

* In GitLab member or Email address field: search for Natasha Edwards (user name: scmne)

* In Select a role dropdown menu, choose Maintainer

1

* Click on Invite button

* Repeat for Martin Chorley (user name: scm2mjc), making sure the role permission is also set as Maintainer.

– Your git repository must include a README text file (.txt or .md), which contains the following information:

* Your Student Number

* (If deployed on OpenShift) URL of your website on the OpenShift server;

* full (40 characters) CHECKSUM of your last commit performed on your repository on COMSC GitLab (see Appendix A). This will be used to check the timestamp of the latest commit (changes) in your repository.

* [OPTIONAL] References.

– Note: no changes are allowed after the submission deadline! Non compliance with this requirement, i.e. working on the coursework after the deadline, may be penalised and may result in capping the mark at the pass rate (for the work submitted < 24 hrs late) or an award of zero marks (> 24 hrs late submission).

• For item (3) - specific requirements for your report on the website’s security and usability are given in Section 3.

• For item (4) - you will need to fill in and submit the online ’’CMT120 - CW 2 - Submission Details Form (21-22)’ form, the link to which will be posted in ’Assessment’ area on Learning Central. !! Please note: the form is set as anonymous and can only be submitted once. Please make sure to fill in the details required accurately to avoid unnecessary issues and delay.

Any code submitted will be run on a system equivalent to the laptops provided to the students, and must be submitted as stipulated in the instructions above. The code should run without any changes being required to the submitted code, including editing of filenames.

Any deviation from the submission instructions above (including the number and types of files submitted) may result in a deduction of up to 25% from the overall mark.

Staff reserve the right to invite students to a meeting to discuss coursework submissions.

2

INSTRUCTIONS

For this coursework, you are asked to develop a personal web blog, which showcases your competences, skills and expertise, e.g. your technical skills, previous work experience, etc. - the choice of what you want to cover its up to you, but make sure you cover a reasonable range of these. It might be helpful to think about this website as your personal digital portfolio.

The website is to be implemented using Flask micro web framework.

1 Structure and Functionality of the Website

Your website should allow your visitors to browse through the posts (articles) you have published, leave comments, and contact you using email and LinkedIn (the link for the latter can be just a placeholder - you do not have to create a LinkedIn account). Access to your website must not be limited to registered users only, i.e. all web pages are accessible without the need to log in first.

Your website should have the following functionality:

1.1 Web Pages

Your website will have a number of pages to display content to visitors. Each web page should have:

• Header with a navigation bar to enable access to all pages. All users must be able to see the links to home and login, but the navigation bar should distinguish between registered logged-in users and guests, as follows:

– The visitor, who is not registered or logged in will see ’Hello, Guest!’ message, and should have access to registration or login functionality.

– A registered logged-in user should see a personalised greeting, i.e. be greeted by their first name (e.g. ’Hello, Jane!’), and should only see an option to log out.

• Main body section that displays the content appropriate to each page.

• Footer containing relevant links to additional information, e.g. contact details, privacy policy, disclaimer, etc.;

• You can also include a side bar to display any information you think is relevant and makes your website more attractive and usable.

All content on the website should be generated pragmatically, i.e. pulled from the databases, not ’hardcorded’ manually.

3

1.1.1 Home Page

Home page should use a template home.html, and allow visitors to:

• view a short description (summary) of each posts (max 3-4 lines) in the appropriate location on the page;

• access an individual post by click on either the selected post’s title or post’s image;

• sort the posts by ascending or descending date.

1.1.2 Individual Post Pages

Create 3-4 individual post pages.

• Each individual blog post page should use a template titled post.html.

• Each page will display detailed information about a particular post.

• Registered users should be able to post comments and rate each post on scale of 1 to 5 stars - by selecting appropriate number of stars. When a user post a comment, the user name should be displayed along with the comment content. The user comments and rating should be displayed correctly immediately after posting (i.e. without any delay due to moderation).

1.1.3 User Accounts

Your website should have appropriate pages to allow your visitors to register, log in and log out.

• Registration:

– Registration form should use register.html template.

– Registration form should be shown to the user on the register page. The form should contain the following fields for the user to input their details: first name, email, password and repeat password fields.

– Simple checks of user input should be performed, such as that their email address is in the expected format (e.g. my_email@some_domain.com), first name and password contain alphanumeric characters only, and both passwords match.

– On valid user input:

- a user account is created, - a confirmation message is displayed, - the system logs in the successfully registered user and redirects to the

home page.

– On invalid user input:

- Error messages are shown when the user incorrectly fills in the form: · For invalid email: "Invalid email. Please check." · For invalid password: "Your password contain invalid characters.".

4

· For non-matching passwords: "Passwords do not match. Please try again."

– If registration is unsuccessful, the user should be informed by displaying an error message "Sorry, there is a problem with your registration", and should not be redirected to any other page.

• Log in functionality:

– The user is able to log in with the correct credentials (email and password) on the login page.

– On successful log in: the user is redirected to the home page.

– If the user cannot log in, she or he is redirected to an error page where a message "Incorrect email or password supplied." is shown to the user.

• Log out:

– The user is able to log out by clicking on the corresponding link on the top navigation bar.

– On successful logout, a confirmation message "You have been logged out." is displayed.

• Test User Account:

– Your database must contain a test user account with the following details:

* email: [email protected]

* password: passuser1

!! IMPORTANT !! The elements/components present on the website must adhere to the specification laid out in Appendix B.

5

2 Deployment on OpenShift

Deploy your website on OpenShift following the instructions given in the lab sheet and demonstrated in one of the practical sessions. Make sure you state the correct URL in your REAMDE.txt submitted on Learning Central. If this is missing or incorrect, no marks for website deployment will be awarded, and you website will be marked based on the code pushed to GitLab.

3 Report on Website’s Quality, Usability and Security

Write a report of maximum 1000 words (± 10%), in which you discuss your website’s quality, usability and security.

Your report will contain:

• Screenshots of all pages.

• Self-assessment of the website’s quality, usability and security:

– As a suggestion, you might want to critically appraise your work whilst thinking about:

* Is the content appropriate? Does it cover a reasonable range of my competences and skills?

* Is my website aesthetically pleasing? Does it have appropriate and consistent ‘look and feel’? Professionally presented? Is the content nicely laid out on all pages?

* Is navigation intuitive, consistent and self-explanatory, with clear navigational menus on all pages providing access to all other parts of the site without breaking the logic of operation?

* Can I claim that my website secure? How is security ensured?

These questions are just a suggestion on what you can discuss, and you are encouraged to think about other aspects you consider as relevant to your work. Make sure you don’t just describe the chosen aspects, but provide compelling, insightful, fully justified arguments.

Rules, Restrictions and Further General Comments

• The software tools and technologies that are to be used for developing your website are HTML, CSS, JavaScript and Python/ Flask.

• Use of libraries, APIs, etc. is allowed, however, the final code must be authored by you. If you use external libraries, APIs, etc. you must provide complete references in your code and in README.txt file.

• The website content must be ’dynamic’, i.e. pulled from a database. You can employ any type of database system/service. Static, ’hardcoded’ web pages are not acceptable.

6

• Use of the code you developed when working on the lab exercises for this module is allowed.

• You must use School-based systems and servers. The use of external services is not allowed.

• There is no need to produce a user guide as it is assumed that the website interface will be self-explanatory.

• You are reminded of the need to comply with Cardiff Universitys Student Guide to Academic Integrity. If you use external resources, these need to be properly referenced, e.g. as in-line comments in your code, or in the README file. Evidence of unfair practice will be penalised. You should also read the Schools electronic coursework submission policy, available on Leaning Central.

Good luck!

7

Learning Outcomes Assessed

• LO3: Develop secure web applications that make use of database technologies

• LO4: Critically appreciate the role of security, quality and usability within software projects

Criteria for assessment

Credit will be awarded against the following criteria, depending on the part:

Functionality of website: Does the functionality works correctly? Is the system robust under all conditions?

Quality of report: Is the report organised well? Does it offer a focused discussion? Is all information presented in the report relevant? Is the argument fully justified?

The mark breakdown for each part is as follow:

• Home page: 10 marks

• Individual pages: 30 marks

• User account functionality: 10 marks

• Deployment on OpenShift: 15 marks

• Report: 20 marks

[Total: 85 marks]

For each item evaluated, partial marks can be assigned as illustrated in the following table.

8

Distinction (70-100%)

Merit (60-69%)

Pass (50-59%)

Fail (0-49%)

Website Functionality

Functionality described in the instructions fully works. There are no detectable bugs. The system is robust under all circumstances.

Functionality described in the instructions mostly works. Some inconsequential bugs that do not substantially affect the operation of the website. The system remains stable during normal usage, but fails when the examiner deliberately tries to break it.

Only partially functioning features. There are obvious bugs that substantially affect the operation of the website. The system behaves unpredictably during normal usage. Serious flaws in several functions. Persistent bugs affecting the functionality of the website.

Functionality not implemented, or completely faulty implementation with wrong behaviour and/or output.

Report Quality The content is of very high quality. It provides an interesting, insightful, focused discussion, demonstrating an excellent ability to choose relevant information and present a highly effective, fully justified argument.

The content is of good quality but needs some improvement. Good ability to choose relevant information and present a good argument, albeit justification needs to be stronger.

The content is of reasonable quality, but requires substantial improvement. Limited ability to choose relevant information. Very little justification.

The content is either missing or very limited and is in need of major improvement, e.g. information is unfocused, disorganised or irrelevant.

Feedback and suggestion for future learning

Feedback on your coursework will address the above criteria. Feedback and marks will be returned on the return date via email. The feedback from this assignment will be relevant for any future programming tasks.

9

Appendix A: Checksum of your last commit on GitLab

To access the checksum of your last commit, go to the Project’s main page, and click on the button next to the 8-character text - see Fig. 1. This will copy the full checksum (i.e. 40 characters). Paste the copied text into your README.txt file.

Figure 1: Accessing checksum of your last commit on GitLab

10

Appendix B: Specification for Blogging Website's Elements/ Components

The following are the 'MUST' requirements for the Blogging website:

All pages:

• a navigation bar at the top of each page must have HTML ID 'top_navig_bar', and must include clickable elements with the following HTML IDs (the order of how these are displayed is not important - this is your design decision): • 'home' (must lead straight to home page) • ‘login’ (must lead straight to login page) • ‘register’ (must lead straight to register page) • 'pers_greet' (must show 'Hello, Guest!' message for unregistered or not

logged-in users, and 'Hello, <LOGGED-IN USER's FIRST NAME>!' • ‘logout’ (shown to the logged-in users; must immediately log out without

confirmation and return to home page) • A page footer with ID 'footer'.

Home page • The homepage must show at least 3 posts and corresponding short descriptions. • The posts must be grouped in an element of HTML class 'blog_post'. • For each post:

o Title must have HTML class 'post_title' o Short description must have HTML class 'short_description'

• The posts collection must be sortable using a SelectField which includes the value date_asc and date_desc. Selecting each option must immediately sort the posts to change display order. (Hint: use WTForms.)

Individual Post page

• Title must have HTML class 'post_title' • Short description must have HTML class 'detailed_description' • Comment text section must have class 'comment_text' • Rating section must have class 'post_rating'

Register page

• Input field for username must have HTML ID ‘first_name_new’ • Input field for username must have HTML ID ‘email_new’ • Input field for password must have HTML ID ‘password_new’ • Password confirm field must have HTML ID ‘password_confirm’ • Both must accept up to 20 characters (letters and numbers) • There must be one and only one submit button

11

Login page

• Input field for username must have HTML ID ‘username’

• Input field for password must have HTML ID ‘password’

• Both must accept up to 20 characters (letters and numbers)

• There must be one and only one submit button

• Successful login must redirect to the home page

• Unsuccessful login must load an error page where the error message has HTML class ‘login_error’

Where HTML IDs and classes have been specified above, these IDs and classes must not be used for any elements other than those described.

12