CSCI 2170 Assignment 3

CSCI 2170 Assignment 3

$30.00

Download Details:

  • Name: A3-bckhrq.zip
  • Type: zip
  • Size: 777.94 KB
Category:

Description

5/5 - (1 vote)

Purpose

  • The purpose of this assignment is for you to apply your knowledge of server-side scripting to (a) find/fix errors in a codebase, and (b) work with databases.
  • In this assignment, you will apply your knowledge of PHP and MySQL.

Expectations, in detail

  1. STEP 1: Development:

    • It is ideal to develop the website using your localhost setup and verify its functionality by hosting it on the FCS Bluenose server.
    • You can find out more about the web hosting space assigned to you by accessing https://web.cs.dal.ca
    • You are expected to develop your website to meet the acceptance criteria set out in the user stories below.

  2. STEP 2: Your tasks:

    • Preliminaries:
      • Clone the folder named A3 that is available on Gitlab under CSCI 2170.
      • Preserve the directory structure; do not change it.
      • Create new PHP and/or style/JS/image files if you need to and place these files in appropriate folders in the A3 directory that you clone/download.
      • Update the README.md file with your name, B00 number and the Academic Integrity pledge that you submitted in Assignment 1.
      • Include all citations and references to any external resource and/or code in both in the code and in README.md
      • Some of the instructions require you to make certain assumptions. Any assumptions you make to implement the functionality as expected in this assignment must be described in README.md as a separate section.
    • User Story 1: Error Correction:
      • As a back-end web developer,
        I need to fix all the errors in the given website,
        So that I can use the codebase to add additional features.
      • Acceptance criteria: Fixing all errors in the code:
        • Find and fix all errors in the code that you cloned from Gitlab.
        • You are expected to make changes to the files that you download – you are not expected to create new versions of these files.
        • Fix the errors and use the code to implement the user stories that follow.
    • User Story 2: Database connection and use:
      • As a back-end web developer,
        I need to connect the website to a database,
        so that I can implement functionality such as storing/retrieving/modifying data in a reliable manner.
      • Acceptance criteria: Update db.php to connect to the DB as specified.
        • Hostname: localhost
        • Username: root
        • Password: root
        • Database name: 2170
        • You are expected to work with 3 tables: mindfeed, a3login and a3users. The ERD and table structures are available on Brightspace as separate images that you can download and view for reference.
        • Create a connection object named $conn. We will be using $conn during marking as well.
        • Note:
          • When marking, we may change the DB file to work with our database on Bluenose. If you want to verify whether your file works on the FCS Bluenose server, you will need to change the DB login credentials as specified on https://web.cs.dal.ca under “Databases”. You may have to set it up on https://web.cs.dal.ca if you have not already done so.
          • We will use the same table structures and same table column names. So as long as you have used the same structure referenced in the ERD and table structure diagrams without any typos or case differences, you should be okay.
          • Test your code with your own data input to the DB.
          • If we are unable to execute your code with our table structures, you will not receive any points for the specific functionality.
    • User Story 3: User Visits Homepage of the Website:
      • As a user,
        I need to be able to login to the website,
        So that I can see the contents and post comments to the web page.
      • Acceptance criteria: User lands on (or visits) the homepage.
        • User sees a navigation menu with a link to the page named “The Force” (linking to theforce.php).
        • User sees the homepage with a login option.
          • The login option is either a drop-down option or is embedded in the page and needs the user to submit a user name and a password.
        • If the user is logged in:
          • The user sees their full name in the navigation menu, with a drop-down option to logout appearing when they click on the name.
          • The user sees the commenting interface with the paragraphs of text and headings appearing above the comments.
        • If the user is not logged in:
          • The user only sees the homepage navigation and the banner (that is styled using the “jumbotron” class).
          • The user sees the disabled comment form with a message that says “You must be logged in to interact using this commenting feature.”
          • The user does not see comments posted below the form.
        • Note:
          • You are not allowed to modify any of the design elements of this web page.
          • Do not hard-code the website name to display it on the page header. Instead, write a function named getWebsiteName() and call it to display the website’s name.
      • Acceptance criteria: User clicks on navigation link to “The Force”
        • If the user is logged in:
          • The user is taken to the page named “The Force”, i.e. theforce.php.
        • If the user is not logged in:
          • The user is redirected back to the homepage and an error message is displayed.
          • This page (theforce.php) can only be accessed by a user who is logged in.
    • User Story 4: Posting and Viewing Comments:
      • As a user,
        I need to post and view comments through a web form,
        So that I can interact with the content on the web page.
      • Acceptance criteria: User submits a comment:
        • If the user is logged in,
          • The user sees the form to submit comments to the web page.
          • The user sees comments (previously submitted by anyone) below the form.
          • The user can submit more comments using the form.
          • The user can use the “clear” button to remove all data from the form.
        • If the user is not logged in,
          • The user sees a disabled comment form.
          • The user does not see the comments.
      • Acceptance criteria: User scrolls the page to view comments
      • If the user is logged in,
        • Below the form, the user sees all comments, both posted by this logged in user and other users of the website.
      • If the user is not logged in,
        • The user does not see any comments. The user sees a note that says “You must be logged in to interact using this commenting feature.”
      • Note:
        • You are expected to implement the functionality to post comments in the files named post_comment.php and view_comments.php. These files are located in the includes folder.
        • Try to implement the post comment and view comment features as two independent and re-usable scripts. This helps you to simply “plug-n-play” these features on other pages as well. See theforce.php to get an idea of what is expected.
        • Hint:
          • Move the script to process all comment-related requests (both post and view) into a new file named process_comments.php, which works as follows:
          • This serves as a comment “controller” of sorts in terms of the MVC terminology. You would submit all data requests and data to-be-submitted to this controller, which would then process the data as required.
    • User Story 5: Login and Session Management:
      • As a user,
        I need to login (and logout) from the website,
        So that I can securely interact with the content on the web page.
      • Acceptance criteria: User submits login information (username and password):
        • The website compares the username and password combination.
        • If the user enters the correct login information,
          • The user is logged in.
          • A new navigation menu link appears with the user’s full name. This has a drop-down action that shows a link to logout.
        • If the user enters the wrong login information,
          • The user sees an error message below the login form, in red colour, indicating the error.
          • The user is *not* logged in.
      • Acceptance criteria: User selects the logout option from the drop-down navigation:
        • The user is logged out.
        • The user logout drop-down menu item is removed from the navigation menu.
        • The user does not see the comments and the comment box is disabled.
      • Note:
        • Set up the tables as specified in the user story named Database Connection and Use. You’ll need to use these tables for the login feature.
        • Update the login form (that you implemented in the homepage) so that the form will be processed by the file named login.php (stored in the includes folder).
        • login.php must perform the following actions:
          • Process the login information and authenticate (or, verify) the user, i.e. compare the username and password submitted by the user with details stored in the DB, and verify that records match.
          • The user is expected to provide their username (not email address) along with their password.
          • If the user has entered wrong login information, i.e. if there is an error in either the username or password, do the following:
            • Return an appropriate error code and redirect the user to the homepage. Describe the error code you will use and how you will implement it in README.md
            • Clearly indicate through an error message that there has been an error. I will leave the content of the error message up to you. Ensure that this error message is in a colour that is different from the regular text so that it is emphasized. This feedback to the user also ensures that you have implemented “Visibility of System Status”, which is one of the important Usability Heuristics.
            • Store user details such as full name, username and user type as session variables, since they may be needed for other features.
            • Implement the logout feature in logout.php stored in the includes folder. This file must log the user out by destroying the session appropriately. There is one standard way of doing this as discussed in class. Please use it and cite it appropriately.
        • You are not expected to implement security in this login processing. We will do that in the next assignment.
    • Citations:

  3. STEP 4: What do I submit?

    • You are required to submit this assignment in two places — (a) Brightspace, and (b) Gitlab.
    • Submission on Gitlab —
      • Instructions to submit assignments on Gitlab (https://git.cs.dal.ca/) have been posted in a section under “Content >> Assignments” — if you have any questions, please reach out to the CS Help Desk.
    • Submission on Brightspace — A single zip file named <LASTNAME>_<FIRSTNAME>_B00XXXXXX_A3.zip
      • Replace <LASTNAME> with your last name, and <FIRSTNAME> with your first name.
      • Replace “B00XXXXXX” with your B00 number.
    • The above ZIP file should preserve the directory structure available in Gitlab. You may add additional PHP and/or other files as needed. Include a summary of the files you have added and why in README.md

  4. STEP 5: Milestones and Marking Scheme

    • Milestones: 
      • You are expected to attend the labs/tutorials on 28 Feb and 13 Mar to demonstrate progress in your assignment.
      • This makes you eligible to get 10 marks of your final assignment score, i.e. 5 marks each for demonstrating progress in the tutorials on 28 Feb and 13 Mar.
      • Otherwise, your score will be graded out of 100% and scaled down to 90.
    • Detailed marking scheme is available in this PDF document.

 

 

 

 

Related products