Why authentication needs server-side logic in Astro - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to import the server-side authentication function.

Astro

import [1] from '../server/auth.js';

Drag options to blanks, or click blank then click option'

AuseState

Brender

CfetchData

DauthenticateUser

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing client-side hooks like useState instead of server functions.

The authenticateUser function runs on the server to check user credentials securely.

2fill in blank

medium

Complete the code to call the server-side authentication inside an Astro server function.

Astro

export async function POST({ request }) {
  const data = await request.json();
  const user = await [1](data.username, data.password);
  return user ? new Response('Success') : new Response('Fail', { status: 401 });
}

Drag options to blanks, or click blank then click option'

AauthenticateUser

BfetchUserData

CrenderPage

DhandleClick

Attempts:

3 left

💡 Hint

Common Mistakes

Using client-side functions that don't handle authentication.

The authenticateUser function verifies credentials on the server and returns user info if valid.

3fill in blank

hard

Fix the error in the server-side authentication response by completing the missing header.

Astro

return new Response(JSON.stringify({ message: 'Success' }), { status: 200, headers: { '[1]': 'application/json' } });

Drag options to blanks, or click blank then click option'

AAccept

BAuthorization

CContent-Type

DCookie

Attempts:

3 left

💡 Hint

Common Mistakes

Using headers like Authorization or Cookie which are for requests, not response content type.

The Content-Type header tells the browser the response is JSON data.

4fill in blank

hard

Fill both blanks to securely store and check the user's session token.

Astro

const token = request.headers.get('[1]');
if (!token || !isValid[2](token)) {
  return new Response('Unauthorized', { status: 401 });
}

Drag options to blanks, or click blank then click option'

AAuthorization

BSession

CToken

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect header names or validation function names.

The Authorization header carries the token, and isValidToken checks if it's valid.

5fill in blank

hard

Fill all three blanks to create a secure server-side login handler that sets a cookie.

Astro

export async function POST({ request }) {
  const { username, password } = await request.json();
  const user = await [1](username, password);
  if (!user) return new Response('Unauthorized', { status: 401 });
  return new Response('Logged in', {
    status: 200,
    headers: {
      '[2]': `token=${user.token}; HttpOnly; Secure; Path=/; Max-Age=[3]`
    }
  });
}

Drag options to blanks, or click blank then click option'

AauthenticateUser

BAuthorization

C3600

DSet-Cookie

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong header names or forgetting to set HttpOnly and Secure flags.

The server authenticates the user, then sets a secure cookie with Set-Cookie header and a max age of 3600 seconds (1 hour).

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