CSG2431 Interactive Web Development

Password Hashing

Volunteer and organiser passwords can no longer be stored in plaintext in the database instead, a hash of the password should be stored. This will involve modifying the code that processes the volunteer registration form and the code that processes the login forms. See Module 9 for details and code examples of how to do this.

Also create an organiser registration page which is not linked to from any other page of the website. The organiser registration form should consist of a username field, a password field, and a password confirmation field. The validation must ensure that the username does not already exist, and the password is at least 5 characters long and matches the confirmation.

The organiser registration form should also contain an access code password field to ensure that only people who know the access code can register new organisers. The access code is CSG2431: If the access code field does not contain this value, do not add the new organiser to the database. Only check this in the server-side validation so that the access code cannot be discovered by clients.

You will need to change the passwords of existing volunteers and organisers in the database to hashes so that they can log in once you have implemented the above feature. To do this, generate a hash of their plaintext password using code from Example #1 of the password_hash() documentation and replace their plaintext password in the database with the resulting password hash.

18+ Tasks

Details of tasks must now include whether the task can only be allocated to volunteers that are at
least 18 years old, and this must be enforced when organisers allocate tasks to volunteer time slots.
This will involve changes and additions to both the volunteer and organiser sections of the website:

The volunteer table in the database will need a new column to store the volunteers date of birth,
and the volunteer registration form will need a field for this a HTML5 date input could be used.
You do not need to enforce a minimum age for volunteers when registering.

A new column will also be needed in the task table to record whether the task is 18+ only, and a
new field is needed in the forms for adding and editing tasks in the organiser section of the website.
A checkbox field could be used. Display whether a task is 18+ when displaying task names.

When allocating a task to a volunteer time slot, you must ensure that 18+ tasks can only be allocated to volunteers that are at least 18 years old at the current time. PHPs strtotime() function will be very useful in checking this: It can be given a string of a date and will return a Unix timestamp representing it as a number of seconds, e.g. strtotime('2000-09-05') returns 968083200. It can also be passed strings such as 18 years ago and will return a Unix timestamp relative to the current time. Unix timestamps can easily be compared to determine if one date is later than another.

Changing Duration

Organisers should now have the ability to change the duration of the convention to a number of days between 1 and 7 via a form accessible in the organiser section of the website. The form needs a field that allows the user to specify the desired duration. This fields default value should be the current duration of the convention. The current duration of the convention can be determined by dividing the number of rows in the time_slot table by 3, since there are 3 time slots per day.

When the duration is increased (new duration is more than current duration), insert Morning, Afternoon and Night time slots for each additional day into the time_slot table of the database. For example, increasing from 2 to 4 days would involve inserting 6 new time slots - Morning, Afternoon and Night for Day 3 and Day 4.

Implementing this will involve thinking through the problem and breaking it down into a series of steps. It will involve some simple arithmetic and using loops to generate INSERT statements.

When the duration is decreased (new duration is less than the current duration), prompt the user to confirm their decision and if they do so, delete any time slots beyond the new duration. For example, decreasing from 4 days to 1 would delete all the time slots for Days 2, 3 and 4 from the time_slots table. This should also delete all volunteer time slots for those days. This can be achieved by adding cascading delete behaviour to the foreign key constraint via the relation view in phpMyAdmin.

Implementing this will also involve thinking through the problem. One approach would be to determine the time slot ID of the Night time slot of the last day of the new duration, then delete any time slots with a time slot ID greater than that.

Event Logging

Whenever a significant event happens on the website, a log of it should be recorded in the database. Logs will be inserted into a log table in the database, which needs the following columns:

log_id an auto incrementing integer (primary key)

log_date a TIMESTAMP column which has a default value of the current date and time

ip_address the IP address of the user who performed the action

event_type a short description of the event that occurred, e.g. Task Deleted

event_details a detailed description of the event, e.g. Order Pizza task deleted by bevans

Event details should include relevant emails, usernames, time slot names and task names so that it is clear which data the event involves.

The following events must be logged:

Registrations, logins and failed login attempts for volunteers and organisers

Volunteers adding and removing time slots

Organisers allocating tasks to volunteer time slots and clearing volunteer time slots

Organisers adding, editing and deleting tasks

Organisers increasing and decreasing the duration of the convention.

See Module 9 for details and code examples of how to implement event logging. It will involve adding code to INSERT data into the log table at the points where these events occur in your code. Since the process is mostly the same regardless of event type, this can be streamlined by defining a function.

A page to view the logs in the log table should be created, only accessible to organisers. All details of logs should be shown (except the log ID), and they should be ordered by date (in descending order).

Database Change Summary

Here is a summary of the database changes needed to implement the new features:

The volunteer table needs to ensure that the password column is long enough to contain a password hash (and consider renaming the column to reflect that it contains a hash), and needs a new column to store the volunteers date of birth (use the DATE data type).

The organiser table needs to ensure that the password column is long enough to contain a password hash (and consider renaming the column to reflect that it contains a hash).

The task table needs a new column to store whether the task is for 18+ volunteers only.

A log table needs to be created, containing log_id, log_date, ip_address, event_type and event_details columns.

Sample Content and Submission of Deliverables

Your database must contain enough sample data for me to test the new features.

Once your assignment is complete, re-read the entire brief to make sure you have implemented everything that is asked for. Then, submit the following in a zip file:

The folder inside your htdocs folder which contains your code files. Make sure you have used relative paths for all links it should work regardless of the folder/path name.

A creation script for your database, exported using phpMyAdmin (see Task 6 of Workshop 2).

A readme.txt file containing your name(s) and student number(s), login details for all users, references for external resources youve used, and any other relevant information.

Submit the zip file to the appropriate location in the Assignments area of the unit site. If you are working in a pair, either student can make the submission the same grade and feedback will be applied to both students.

Academic Integrity and Misconduct

The entirety of your assessment must be your own work or the work of your pair (unless otherwise referenced or provided as unit content). Any unreferenced content you did not create is academic misconduct (plagiarism). Assessments are submitted to plagiarism checking software which includes previous assessments, and the work submitted by all students in the unit. Submissions are also manually compared and checked. Do not make your work available online, during or after the unit.

Remember that this is an individual/pair assessment. Never give anyone any part of your assessment even after the due date or after results have been released. You can help someone by explaining a concept or directing them to the relevant resources, but doing any part of the assessment for them or alongside them, giving them a copy of your work, or showing them your work, is inappropriate. An unacceptable level of assessment-related collaboration between students who are not officially working together is academic misconduct (collusion). If you are uncertain about plagiarism, collusion or referencing, simply contact your tutor, lecturer or unit coordinator.

You may be asked to explain and demonstrate your understanding of the work you have submitted. Always remember that the purpose of an assessment is for you to demonstrate your understanding of the unit content and your ability to apply it to the task presented to you.

Are you struggling to keep up with the demands of your academic journey? Don't worry, we've got your back! Exam Question Bank is your trusted partner in achieving academic excellence for all kind of technical and non-technical subjects.

Our comprehensive range of academic services is designed to cater to students at every level. Whether you're a high school student, a college undergraduate, or pursuing advanced studies, we have the expertise and resources to support you.

To connect with expert and ask your query click here Exam Question Bank