I was tasked with creating the back-end for a typical job recruitment website, that caters to the needs of both recruiters & job seekers. Since I didn’t have to create the front end designs, I kept the UI work minimal, only building simple frameworks for tables.
I started by planning out how my website would work, by creating multiple design documents such as flowcharts of system operations, Use-case & Entity-Relationship diagrams. I looked carefully at how different types of users would expect the platform to behave and how to best cater to that, whilst maximising efficiency and security. I also considered the operation of the system, in terms of not allowing users who are not logged in to post applications .etc
Building & Operation (in brief)
Firstly, users can create a login with a name, email and password. This is checked against the database, and if an account doesn’t already exist, it is then stored within the database.
Then users can login, opening a session that will last either until the browser is closed or the logout button is pressed. When a session is started, a user can upload a job listing or application (provided there are jobs already posted) and this will be linked to their account using the current session data. Sessions also work when it comes to applying for a job – once a user has selected a job from the job search, the primary key of that job is temporarily stored, meaning that the application is automatically linked to that listing for ease of viewing by a recruiter.
Files such as CV uploads are typically too large to be stored in a database – instead, I programmed it so that the location of the file is saved in the SQL database, allowing a recruiter to simply hit a download button to view it later.
Some information, such as which users posted which jobs or applications, is cross-referenced between tables. In these cases, primary keys are also used (for example to link applications to the appropriate job listings).
When it comes to website security, there is a lot more to consider than just passwords. When building a website of this nature, there is often extra risks, such as stored user information & file uploads.
I used PDO (Php Data Objects) instead of MySQLi, as it uses prepared statements; making it more secure against SQL injection attacks. Unlike mySQLi, which only works on SQL databases, PDO works on many, meaning that switching to another database later on requires minimal effort.
File uploads, in this case CV uploads, create potential for attacks. This can be combated by conducting multiple checks before a file is allowed to be uploaded to the server. This includes file size limits & checking for file types. Since this is still not perfectly secure, extra steps can be taken, such as renaming a file and using a new extension — ensuring that uploaded files are non-executable.
All user data is stored hashed, so in the event of a data breach, user information is kept safe and secure. A separate username & password is used for database operations only (as opposed to full root access), which is hidden from viewing by site visitors.