# How the freeCodeCamp User Reporting System Handles Blocked Users

> Learn how freeCodeCamp's reporting system blocks users, preventing abuse reports with HTTP 400 errors and Auth0 redirects for suspended accounts.

- Repository: [freeCodeCamp.org/freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp)
- Tags: internals
- Published: 2026-02-23

---

**The freeCodeCamp user reporting system prevents blocked entities from submitting abuse reports by rejecting automated scripts at the routing layer with HTTP 400 errors and intercepting suspended accounts at the authentication layer via Auth0 redirects.**

The freeCodeCamp open-source platform maintains strict access controls to prevent abuse of its reporting infrastructure. According to the `freeCodeCamp/freeCodeCamp` source code, the user reporting system handles blocked users through two distinct defense mechanisms that operate before any protected endpoint logic executes.

## Two Layers of Blocking Protection

The platform implements complementary blocking strategies at different architectural layers to ensure neither automated scripts nor suspended human accounts can file reports.

### Blocking Automated User Agents at the API Layer

Before any authentication occurs, the public API routes filter out known automation tools. In [`api/src/routes/public/user.ts`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/api/src/routes/public/user.ts) (lines 95–118), the system inspects the incoming request's `User-Agent` header against a blocklist:

```typescript
blockedUserAgentParts = ['python', 'google-apps-script', 'curl']

```

If the user agent string contains any of these substrings, the route immediately returns **HTTP 400** and terminates the request. This prevents scripted attacks from ever reaching the reporting logic or consuming authentication resources.

### Suspending Accounts via Auth0 Authentication

For human accounts disabled by the moderation team, the blocking occurs during the authentication phase. The **Auth0 plugin** located in [`api/src/plugins/auth0.ts`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/api/src/plugins/auth0.ts) (lines 113–119) validates the user's status during the JWT verification process.

If the account is marked as blocked in Auth0, the plugin executes:

```typescript
reply.redirect(`${HOME_LOCATION}/blocked`)

```

This redirects the browser to the `/blocked` page before issuing a valid token. Because the reporting endpoint requires authentication, a suspended user cannot obtain the necessary JWT to reach the protected route.

## End-to-End Reporting Flow for Legitimate Users

When a reporter passes both blocking layers, the system processes their submission through a coordinated client-server flow.

### Client-Side Report Initiation

The reporting process begins in the React/Redux client layer. The UI dispatches the `reportUser` action defined in [`client/src/redux/actions.ts`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/client/src/redux/actions.ts) (lines 82–84). The `createReportUserSaga` in [`client/src/redux/report-user-saga.js`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/client/src/redux/report-user-saga.js) (lines 8–16) intercepts this action and executes `postReportUser`:

```javascript
function* createReportUserSaga({ payload }) {
  try {
    yield call(postReportUser, payload);
    yield put(createFlashMessage({ type: 'success', message: 'flash.report-sent' }));
  } catch (e) {
    yield put(handleError(e));
  }
}

```

On success, the saga triggers a flash message confirming the report was sent.

### Server-Side Validation and Processing

The protected endpoint at `/user/report-user` in [`api/src/routes/protected/user.ts`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/api/src/routes/protected/user.ts) handles the actual submission. The route first validates the payload against `schemas.reportUser` defined in [`api/src/schemas/user/report-user.ts`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/api/src/schemas/user/report-user.ts) (lines 4–27), which enforces required fields like username and reason.

The handler logic (lines 74–124) then:

1. Looks up the reported user by username, returning **404** if not found
2. Composes an email to `support@freecodecamp.org` CC'ing the reporter
3. Returns the `flash.report-sent` payload to confirm receipt

## Summary

- **Blocked user agents** (Python scripts, curl, Google Apps Script) receive an immediate **HTTP 400** rejection at the public route level in [`api/src/routes/public/user.ts`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/api/src/routes/public/user.ts)
- **Blocked accounts** are redirected to `/blocked` by the Auth0 plugin in [`api/src/plugins/auth0.ts`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/api/src/plugins/auth0.ts) before obtaining authentication tokens
- **Legitimate users** flow through Redux sagas to a protected endpoint that validates input, verifies the target user exists, and emails support@freecodecamp.org
- The architecture ensures reporting capabilities are inaccessible to both automated tools and suspended human accounts

## Frequently Asked Questions

### What happens if a blocked user tries to access the reporting endpoint directly?

A blocked user cannot successfully call the reporting endpoint. Automated tools are rejected at the network layer by user agent filtering in [`api/src/routes/public/user.ts`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/api/src/routes/public/user.ts), while suspended accounts are intercepted by the Auth0 plugin in [`api/src/plugins/auth0.ts`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/api/src/plugins/auth0.ts) and redirected to `/blocked` before receiving a valid JWT.

### Which specific user agents are blocked from accessing freeCodeCamp's API?

The system blocks requests containing `python`, `google-apps-script`, or `curl` in their User-Agent header. This blocklist is defined in [`api/src/routes/public/user.ts`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/api/src/routes/public/user.ts) and returns HTTP 400 for any matching request.

### How does the system validate report submissions from legitimate users?

Legitimate submissions are validated against the `schemas.reportUser` schema in [`api/src/schemas/user/report-user.ts`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/api/src/schemas/user/report-user.ts), which enforces required fields and data types. The protected route handler in [`api/src/routes/protected/user.ts`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/api/src/routes/protected/user.ts) also verifies that the reported username exists in the database before processing.

### Where does the report data go once a legitimate user submits it?

The system sends an email to `support@freecodecamp.org` with the abuse details, CC'ing the reporter's email address. The client receives a `flash.report-sent` confirmation message via the Redux saga in [`client/src/redux/report-user-saga.js`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/client/src/redux/report-user-saga.js).