Home › Staff sign-in
Staff sign-in
Choose a role to see the same system from a different chair. Permissions are not about distrust — they are about not asking somebody to be careful with a screen they never needed to see.
No password is asked for and none should be entered anywhere on this site. Choosing a role below only changes which screens the demonstration shows and whose name is written into the records you capture. Real access control for this resource is handled in front of the site, not inside it — see the section below.
Who does what
Lerato Mokoena
Owner
Can do: Everything, including prices, reports and the POPIA register.
Sees the whole business. Is also the Information Officer under POPIA, whether or not she has been told so.
Sipho Dlamini
Counter staff
Can do: Ring up sales, look up products, create a customer.
Cannot change prices or see margin. Not because he is not trusted — because he should not have to be careful with a screen he never needs.
Anja van Wyk
Bookkeeper
Can do: Sales, customers, statements and reports.
Needs the financial picture, does not need to touch stock levels.
Thabo Nkosi
Storeman
Can do: Stock movements, deliveries, stock takes, product records.
Lives in the yard. Never needs to see what a customer owes.
Not for secrecy. Three practical reasons: a smaller screen is a faster screen, mistakes get contained to the area the person works in, and the audit trail becomes meaningful — "Thabo adjusted this stock figure" is only useful if it could not have been anybody.
How this site is actually protected
The resource is a static website. It has no server, no database and no accounts of its own, which means it cannot check a password — and should not pretend to. Access control belongs in front of it, at the edge.
Public pages
Everything under / and /pages/ is the
educational resource. It is meant to be read by the client and by anyone they share it with.
No protection needed.
The demonstration
If the shop ever wanted /demo/ restricted to staff, the
way to do it on Cloudflare Pages is an Access policy in Cloudflare Zero Trust:
a rule on the path that requires an email one-time PIN or a Google sign-in, checked at
Cloudflare's edge before the page is ever served.
Deployment and Access configuration are written up in docs/deployment.md in the
project folder. Nothing on this page needs to change to switch protection on — the policy is
applied in the Cloudflare dashboard, against the path, not in the site's code.
For the project demonstration, it's advisable to ensure that the submitted website remains accessible to both the lecturer and marker without necessitating account creation or credential entry. The demonstration should exclusively feature fictional customer and transaction data. This approach enables unrestricted access for inspecting pages and evidence, avoiding any login issues.
A sign-in page alone does not ensure an application's security. For websites containing sensitive information or restricted features, it's crucial to secure the underlying pages and data as well. Simply obscuring a button or presenting a login screen is inadequate if individuals can still access that same data via direct links. Server-side checks or suitable access-control mechanisms appropriate for the technology in use should be employed to manage access effectively.
In a physical store setting, each employee should have their own account with permissions tailored specifically to their job responsibilities. Essential security practices include using robust passwords, ensuring secure password storage, implementing session control measures, and promptly revoking access when an employee departs. Passwords must never be stored in plain text or hardcoded into client-side JavaScript. These precautions align with POPIA section 19's mandate for suitable technical and organizational safeguards to protect personal information effectively.
The public demonstration isn't meant to show that a real customer-management system can safely reveal private records. Instead, it aims to demonstrate the proposed workflow without risking anyone's personal information. Before the presentation, if restricted access is activated, it's important that the team tests the website on that computer and verifies that the presenter can display what they need. A login barrier blocking supervisors from seeing what's being demonstrated would defeat its purpose. The best approach is having an open-to-all demo with no actual customer data while stating clearly that a live system needs proper sign-in procedures and security checks in place.