Why authentication needs server-side logic in Astro - Visual Breakdown

Concept Flow - Why authentication needs server-side logic

User enters credentials

↓

Send credentials to server

↓

Server checks credentials

↓

Create session

↓

Send token

↓

User accesses protected page

↓

Server verifies token

↓

Allow or deny access

User sends login info to server, server checks it, creates session or rejects, then controls access.

Execution Sample

Astro

async function login(user, pass) {
  const response = await fetch('/api/login', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({user, pass})
  });
  return response.json();
}

This code sends user credentials to the server to check if they are valid.

Execution Table

Step	Action	Data Sent/Received	Server Logic	Result
1	User enters username and password	user: 'alice', pass: '1234'	N/A	Credentials ready to send
2	Send credentials to server	POST /api/login {user:'alice', pass:'1234'}	Receives credentials	Credentials received
3	Server checks credentials	N/A	Compare with stored user data	Credentials valid? Yes
4	Create session and token	N/A	Generate session ID and token	Session created, token generated
5	Send token to user	Response {token: 'abc123'}	N/A	User receives token
6	User requests protected page with token	GET /protected with token 'abc123'	Verify token validity	Token valid, access granted
7	User requests protected page with invalid token	GET /protected with token 'wrongtoken'	Verify token validity	Token invalid, access denied
8	End	N/A	N/A	Authentication flow complete

💡 Authentication ends after server validates credentials and controls access based on token.

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 5	After Step 6	Final
user	undefined	'alice'	'alice'	'alice'	'alice'	'alice'
pass	undefined	'1234'	'1234'	'1234'	'1234'	'1234'
session	null	null	'session123'	'session123'	'session123'	'session123'
token	null	null	'abc123'	'abc123'	'abc123' or 'wrongtoken'	Depends on token validity

Key Moments - 3 Insights

Why can't the client check the password by itself?

Because the client code can be seen and changed by anyone, so checking password only on client is insecure. The server must check to keep data safe, as shown in step 3 of the execution table.

Why does the server send a token after login?

The token proves the user is logged in without sending the password again. The server creates it in step 4 and sends it in step 5, so the client can use it to access protected pages.

What happens if the token is invalid when accessing a page?

The server denies access, as shown in step 7, because it cannot trust the client without a valid token.

Visual Quiz - 3 Questions

Look at the execution table, what is the server's action at step 3?

A Check if credentials are valid

B Create a session and token

C Send token to user

D User enters username and password

💡 Hint

Check the 'Server Logic' column at step 3 in the execution table.

At which step does the user receive the token?

A Step 2

B Step 4

C Step 5

D Step 6

💡 Hint

Look at the 'Result' column for when the user gets the token.

If the server did not verify the token on protected pages, what would happen?

A The server would create new tokens

B Users could access pages without logging in

C Users would be logged out automatically

D Nothing would change

💡 Hint

Refer to step 7 where invalid tokens cause access denial.

Concept Snapshot

Authentication needs server-side logic because:
- User credentials must be checked securely on the server
- Server creates a session and token after login
- Token is used to verify user on protected pages
- Client cannot be trusted to check passwords
- Server controls access by validating tokens

Full Transcript

Authentication requires server-side logic to keep user data safe. When a user enters their username and password, this information is sent to the server. The server checks if the credentials match stored data. If valid, the server creates a session and generates a token. This token is sent back to the user and used to access protected pages. The server verifies the token each time to allow or deny access. This process prevents users from bypassing login by trusting only client-side checks.

Practice

1. Why is authentication usually handled on the server side in web applications?

easy

A. Because authentication does not need any security

B. Because the server can securely check user credentials and control access

C. Because the client can decide who is allowed without server help

D. Because the client can store passwords safely

Solution

1. Step 1: Understand the role of server in authentication

   The server securely stores user data and verifies credentials to protect sensitive information.

2. Step 2: Recognize client limitations

   The client cannot be trusted to securely store or verify credentials because it can be manipulated.

3. Final Answer:

   Because the server can securely check user credentials and control access -> Option B

4. Quick Check:

   Server handles security = D [OK]

Hint: Server controls access securely, client just sends info [OK]

Common Mistakes:

• Thinking client can safely store passwords
• Believing client can decide access alone
• Ignoring security risks on client side

2. Which of the following is the correct way to send user login data from client to server in Astro?

easy

A. fetch('/login', { method: 'GET', body: JSON.stringify({username, password}) })

B. fetch('/login', { method: 'POST', body: username + password })

C. fetch('/login', { method: 'POST', body: JSON.stringify({username, password}) })

D. fetch('/login', { method: 'POST' })

Solution

1. Step 1: Identify correct HTTP method for sending login data

   Login data should be sent using POST to keep data in the request body, not URL.

2. Step 2: Check data format in request body

   Data should be JSON stringified for proper parsing on server side.

3. Final Answer:

   fetch('/login', { method: 'POST', body: JSON.stringify({username, password}) }) -> Option C

4. Quick Check:

   POST with JSON body = B [OK]

Hint: Use POST and JSON.stringify for login data [OK]

Common Mistakes:

• Using GET method which exposes data in URL
• Sending raw concatenated strings instead of JSON
• Omitting the request body

3. Given this Astro server code snippet handling login:

export async function post({ request }) {
  const { username, password } = await request.json();
  if (username === 'user' && password === 'pass') {
    return new Response('Success', { status: 200 });
  } else {
    return new Response('Fail', { status: 401 });
  }
}

What will the server respond if the client sends username='user' and password='wrong'?

medium

A. Fail with status 401

B. Success with status 200

C. Error with status 500

D. No response

Solution

1. Step 1: Check the condition for successful login

   The server checks if username is 'user' and password is 'pass' exactly.

2. Step 2: Evaluate given input against condition

   Input password is 'wrong', which does not match 'pass', so condition fails.

3. Final Answer:

   Fail with status 401 -> Option A

4. Quick Check:

   Wrong password = 401 Fail [OK]

Hint: Match exact username and password on server [OK]

Common Mistakes:

• Assuming any password works
• Confusing status codes
• Ignoring the else branch

4. This Astro server code is meant to authenticate users but has a bug:

export async function post({ request }) {
  const { username, password } = await request.json();
  if (username = 'admin' && password = '1234') {
    return new Response('Logged in', { status: 200 });
  }
  return new Response('Unauthorized', { status: 401 });
}

What is the bug and how to fix it?

medium

A. Use '===' instead of '=' in the if condition

B. Remove the await keyword

C. Use '==' instead of '=' in the if condition

D. Change Response to JSON response

Solution

1. Step 1: Identify incorrect operator in condition

   The code uses '=' which is assignment, not comparison, causing a bug.

2. Step 2: Use strict equality '===' for comparison in JavaScript

   Replace '=' with '===' to correctly compare values in the if condition.

3. Final Answer:

   Use '===' instead of '=' in the if condition -> Option A

4. Quick Check:

   Comparison needs '===' not '=' [OK]

Hint: Use '===' for comparison, '=' is assignment [OK]

Common Mistakes:

• Confusing assignment '=' with comparison '==' or '==='
• Removing await which is needed
• Changing response type unnecessarily

5. You want to protect a private Astro page so only logged-in users can see it. Which server-side approach is best to check authentication before rendering?

hard

A. Render the page fully and then ask for login

B. Check a JavaScript variable on the client to hide content

C. Use client-side localStorage to store login status

D. Check a session cookie on the server and redirect if missing

Solution

1. Step 1: Understand server-side protection needs

   Server must verify user identity before sending private content to prevent unauthorized access.

2. Step 2: Use session cookies for authentication

   Session cookies are sent with requests and can be checked on the server to confirm login status.

3. Final Answer:

   Check a session cookie on the server and redirect if missing -> Option D

4. Quick Check:

   Server checks session cookie before rendering [OK]

Hint: Always verify login on server before showing private pages [OK]

Common Mistakes:

• Relying on client-side checks only
• Using localStorage which can be manipulated
• Rendering private content before login check