Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Nandini-13/PsycheIT/llms.txt

Use this file to discover all available pages before exploring further.

PsycheIT is built on a simple belief: a student should never have to choose between getting mental health support and protecting their identity. The authentication system is designed from the ground up to collect the absolute minimum — no names, no email addresses, no personal details — so that the fear of being identified never becomes a barrier to seeking help.

Design Principles

PsycheIT’s auth model is intentionally minimal and privacy-forward:
  • No email required. Students identify themselves only with a college code (e.g., SRMIST, BITS, IIT). No personal identifiers are ever requested.
  • Non-personal userId. Every account is identified by a string of the form {collegeCode}_{timestamp} — for example, SRMIST_1712345678901. The timestamp component ensures uniqueness without encoding any personal information.
  • Bcrypt-hashed passwords. Passwords are hashed using bcrypt at cost factor 10 before being written to storage. The plaintext password never persists anywhere on the server.
  • Short-lived JWT tokens. On successful login the server issues a JSON Web Token signed with expiresIn: '1h' (one hour). The token is stored in localStorage under the key token and is attached to every session.
  • Zero personal data. No profile, no avatar, no contact information — the server stores only a userId and its bcrypt-hashed password.

Auth Flow

The complete journey from first visit to authenticated session:
  1. Student visits the /auth page in their browser.
  2. Student enters their college code and clicks Sign Up (labelled “Generate Credentials” in the UI).
  3. The backend generates a userId ({collegeCode}_{Date.now()}) and a random 8-character alphanumeric password, then returns both to the browser. Nothing is saved to the server at this point.
  4. The student copies and stores their credentials, then switches to the Log In tab (the UI can auto-fill the fields from the just-generated credentials).
  5. The student enters their userId and password and clicks Sign In.
  6. The backend looks up the userId in users.json. On first login, it bcrypt-hashes the password and saves the record. On subsequent logins, it runs bcrypt.compareSync against the stored hash.
  7. On success, the backend signs a JWT with payload { userId } and returns { token }. The frontend stores the token in localStorage.
  8. All subsequent navigation to protected routes checks localStorage for the token. If it is present the route renders normally; if it is absent the user is redirected to /auth.

Protected Routes

The following routes require a valid JWT stored in localStorage. Unauthenticated users are automatically redirected to /auth:
  • /dashboard
  • /chatbot
  • /resources
  • /blogs/:id
  • /forum
  • /book
  • /screening
Protection is enforced by the ProtectedRoute component, which checks localStorage.getItem("token") on every render.

Security Caveats

The following items must be addressed before deploying PsycheIT to a production environment:
  • JWT secret. The current codebase uses the hardcoded secret "secretKey". Replace this with a long, randomly generated secret (e.g., from openssl rand -hex 64) and load it from an environment variable — never commit secrets to source control.
  • Flat-file user store. users.json is a simple JSON array on disk. It has no concurrency guarantees, no indexing, and no backup strategy. Replace it with a proper database (PostgreSQL, MongoDB, etc.) before going live.

Build docs developers (and LLMs) love