Assignment: Add Authentication and Sessions to Your Scaffolded App

Moodle

Goal

Extend your scaffolded full-stack app so that it supports user authentication and persistent login sessions.

By Monday’s class, your app should be running and demoable. You should be able to demonstrate that a user can log in, remain logged in across requests, and log out successfully.

You may choose one of two paths:

  1. Local Login Path — for apps running on a local/private server
  2. Google Login Path — for apps deployed to a publicly reachable server such as Oracle Free Tier

Both paths must use sessions. A login that works only in the browser without a real server-side session is not sufficient.

Option 1: Local Login Path

If your scaffolded app is running only on a local/private server, you should implement a simple local login system.

Requirements

Your app must support:

  • login with email address as the user ID
  • a simple way for a user to log in
  • creation of a server-side session after login
  • an authenticated route that shows who is currently logged in
  • logout that destroys the session

For this assignment, you do not need to verify that the email address is real. Keep it simple.

Minimum acceptable design

Your app should include:

  • a users table in MariaDB
  • a login form on the frontend
  • backend routes for login, logout, and “current user”
  • session support in Express

A minimal version is fine. For example, a user may enter:

  • name
  • email

and if the email does not yet exist, your app can create the user automatically and log them in.

That is acceptable for this assignment.

Important note

You still need a proper session. That means:

  • the backend stores session data
  • the browser receives a session cookie
  • later requests recognize the logged-in user

Simply storing the email in React state or local storage is not enough.

Option 2: Google Login Path

If you want, you may instead deploy your app to a publicly reachable server and use Google authentication.

A good choice for this is Oracle Free Tier.

Requirements

Your app must support:

  • Google OAuth login
  • creation of a local user record in MariaDB
  • creation of a server-side session after login
  • an authenticated route that returns the current logged-in user
  • logout

Important note

This path only works if your server is publicly reachable, because Google must be able to redirect back to your server after login.

If your server is behind a firewall or only reachable locally, do not use this option unless you have solved that deployment problem.

Core Technical Requirements for Everyone

No matter which option you choose, your app must include all of the following:

Backend

  • Node.js + Express backend
  • MariaDB database connection
  • a users table
  • session middleware
  • login/logout/current-user routes

Frontend

  • a visible login path
  • a visible way to tell whether a user is logged in
  • a visible logout path

Demonstration behavior

At minimum, you must be able to demonstrate:

  1. user logs in
  2. app shows logged-in user
  3. refreshing the page does not lose login state
  4. user logs out
  5. app shows logged-out state

Suggested Minimum Route Design

Your actual routes may vary a little, but they should be close to this.

Local login version

  • POST /auth/login
  • POST /auth/logout
  • GET /api/me

Google login version

  • GET /auth/google
  • GET /auth/google/callback
  • POST /auth/logout or GET /auth/logout
  • GET /api/me

Database Expectations

At minimum, your users table should store enough information to identify the user.

Local login version

A minimal table might include:

  • id
  • email
  • name
  • created_at
  • updated_at

Google login version

A minimal table might include:

  • id
  • google_id
  • email
  • name
  • picture_url (optional but useful)
  • created_at
  • updated_at

What to Keep Simple

This assignment is about getting authentication and sessions working cleanly, not about building a full production identity system.

So for now, keep it simple:

  • no password reset flow
  • no email verification
  • no account recovery
  • no role system unless you want it
  • no JWT requirement
  • no unnecessary frameworks

A clean, understandable solution is much better than an overbuilt one.

What You Must Be Ready to Demo on Monday

In class, you should be ready to show:

If using local login

  • your login form
  • entering a name/email
  • successful login
  • evidence of session persistence
  • logout

If using Google login

  • Google sign-in flow
  • successful login
  • evidence of session persistence
  • logout

You should also be ready to explain, briefly:

  • where sessions are configured
  • how your backend knows who is logged in
  • how your app checks the current user

What to Submit

Submit the following on Moodle by Monday class:

1. GitHub repository link

Submit the GitHub link for your project.

You must also share the repository with jimskon so I can access it.

2. Run information

In your submission, include:

  • the directory where the program lives
  • how to run it
  • if it is on a local server, exactly how I should start it

For example, tell me something like:

  • repository location / main directory
  • how to install dependencies
  • how to start the server
  • what port it runs on
  • whether any .env file is required

Do not make me guess.

3. Brief note on which path you chose

State clearly whether you implemented:

  • Local Login Path, or
  • Google Login Path

Example of the Run Information You Should Provide

Include something like this in your submission:

Program directory:
Fullstack-Software-Development-Demo/server

Install steps:
npm install in server
npm install in client

Build/start steps:
cd client && npm run build
cd ../server && npm start

Server URL:
http://10.192.145.179:4107

Environment file needed:
server/.env

If your process is different, explain your process clearly.

Evaluation

I will mainly be looking for these things:

Functionality

  • does login work?
  • does logout work?
  • do sessions actually persist?

Clarity

  • is the design understandable?
  • is the code reasonably organized?

Correctness of architecture

  • is the backend the source of truth for authentication state?
  • is this a real session-based design?

Demo readiness

  • can you actually show it working live?

Advice

Do not overcomplicate this.

A small, working, demoable authentication system with sessions is the goal.

For many of you, the Local Login Path will be the better choice for Monday. It is simpler, more reliable on a private/local server, and fully appropriate for this assignment.

The Google Login Path is a good stretch option if you already have a public deployment and want to go farther.

Deliverables Checklist

Before you submit, make sure you have all of these:

  • working login
  • working logout
  • working session persistence
  • users stored in database
  • demoable app by Monday
  • GitHub repo submitted on Moodle
  • repo shared with jimskon
  • clear run instructions included
  • clear statement of which auth path you used
Scroll to Top