0Pricing
NestJS Enterprise Backend APIs · 课时

验证并保护 Socket 连接

对握手和消息事件执行守卫与令牌验证，以实现安全的实时访问。

验证并保护 Socket 连接 是 CoddyKit 上的免费 NestJS Enterprise Backend APIs 课时。 这是第 2 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 NestJS Enterprise Backend APIs 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 NestJS Enterprise Backend APIs 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

Why Sockets Need Their Own Auth Story

HTTP routes in NestJS are protected by middleware and guards that read the Authorization header on every request. WebSockets are different: the client opens one long-lived connection during the handshake, then exchanges many messages over it.

  • You authenticate once at connection time, not per message.
  • The socket stays open for minutes or hours, so a token that expires mid-session is a real concern.
  • Standard HTTP guards do not automatically run on WebSocket events.

This lesson shows how to verify a token during the handshake, attach the user to the socket, and guard individual message events for secure realtime access.

Where the Token Lives in a Handshake

A browser WebSocket cannot set custom headers, so clients pass the token in one of three places during the Socket.IO handshake:

  • handshake.auth.token — the modern, preferred slot (set via the client auth option).
  • handshake.headers.authorization — works when a native header is available.
  • handshake.query.token — a fallback, but tokens land in server/proxy logs, so avoid it.

A small helper centralizes extraction so every guard and lifecycle hook reads the token the same way.

import { Socket } from 'socket.io';

export function extractToken(client: Socket): string | null {
  const auth = client.handshake.auth?.token;
  if (typeof auth === 'string') return auth;

  const header = client.handshake.headers?.authorization;
  if (typeof header === 'string' && header.startsWith('Bearer ')) {
    return header.slice(7);
  }

  return null;
}

Verifying on Connection with handleConnection

The cleanest place to authenticate is the gateway's handleConnection lifecycle hook. It runs the moment a client connects. If the token is missing or invalid, call client.disconnect() so the socket never participates in any room or event.

On success, attach the decoded user to client.data — a per-socket bag that survives for the connection's lifetime and is readable in every later event handler.

import { OnGatewayConnection, WebSocketGateway } from '@nestjs/websockets';
import { JwtService } from '@nestjs/jwt';
import { Socket } from 'socket.io';
import { extractToken } from './extract-token';

@WebSocketGateway({ cors: true })
export class ChatGateway implements OnGatewayConnection {
  constructor(private readonly jwt: JwtService) {}

  async handleConnection(client: Socket) {
    try {
      const token = extractToken(client);
      if (!token) throw new Error('No token');
      const payload = await this.jwt.verifyAsync(token);
      client.data.user = { id: payload.sub, role: payload.role };
    } catch {
      client.disconnect(true);
    }
  }
}

Modeling the Authenticated User

Storing client.data.user as an untyped object invites typos later. Define a small interface and a typed helper so every handler reads user.id and user.role with full IntelliSense and compile-time safety.

This is the same JWT payload pattern you use for HTTP routes, keeping authorization logic consistent across both transports.

export interface SocketUser {
  id: string;
  role: 'admin' | 'member' | 'guest';
}

export interface JwtPayload {
  sub: string;
  role: SocketUser['role'];
  exp: number;
}

export function toSocketUser(payload: JwtPayload): SocketUser {
  return { id: payload.sub, role: payload.role };
}

// Demo: a decoded token becomes a typed user
const payload: JwtPayload = { sub: 'u_42', role: 'member', exp: 1893456000 };
const user = toSocketUser(payload);
console.log(`${user.id} connected as ${user.role}`);

Guarding Individual Message Events

Connection-time auth proves who the user is, but some events also need authorization checks — for example, only admins can broadcast a system message. NestJS guards work on WebSocket events too; you just read the socket from the execution context.

Inside a guard, switch the context to ws, grab the client, and inspect client.data.user that handleConnection populated.

import { CanActivate, ExecutionContext, Injectable } from '@nestjs/common';
import { WsException } from '@nestjs/websockets';
import { Socket } from 'socket.io';

@Injectable()
export class WsAuthGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const client = context.switchToWs().getClient<Socket>();
    const user = client.data.user;
    if (!user) {
      throw new WsException('Unauthorized');
    }
    return true;
  }
}

Role-Based Guards with Metadata

To restrict an event to certain roles, combine a custom decorator (storing required roles as metadata) with a guard that reads it via Reflector. This mirrors the HTTP @Roles() pattern, so your team learns one mental model.

The guard rejects the event with a WsException when the connected user lacks the required role — the message handler never runs.

import { SetMetadata } from '@nestjs/common';
export const WsRoles = (...roles: string[]) => SetMetadata('ws_roles', roles);

import { CanActivate, ExecutionContext, Injectable } from '@nestjs/common';
import { Reflector } from '@nestjs/core';
import { WsException } from '@nestjs/websockets';
import { Socket } from 'socket.io';

@Injectable()
export class WsRolesGuard implements CanActivate {
  constructor(private reflector: Reflector) {}

  canActivate(context: ExecutionContext): boolean {
    const required = this.reflector.get<string[]>('ws_roles', context.getHandler());
    if (!required?.length) return true;
    const user = context.switchToWs().getClient<Socket>().data.user;
    if (!user || !required.includes(user.role)) {
      throw new WsException('Forbidden');
    }
    return true;
  }
}

Applying Guards to Subscribe Handlers

Attach guards to message handlers with @UseGuards(), exactly like controller routes. Stack the base auth guard with the roles guard, and decorate the handler with the required roles.

Guards run in declaration order, so put the cheaper authentication check first and the role check second.

import { SubscribeMessage, WebSocketGateway, MessageBody } from '@nestjs/websockets';
import { UseGuards } from '@nestjs/common';
import { WsAuthGuard } from './ws-auth.guard';
import { WsRolesGuard } from './ws-roles.guard';
import { WsRoles } from './ws-roles.decorator';

@WebSocketGateway()
export class AdminGateway {
  @UseGuards(WsAuthGuard, WsRolesGuard)
  @WsRoles('admin')
  @SubscribeMessage('broadcast')
  handleBroadcast(@MessageBody() text: string) {
    return { event: 'broadcast', data: text };
  }
}

Why Guards Alone Miss the Handshake

A subtle gotcha: by default a WebSocket guard runs on message events, not on the initial connection. If you rely only on @UseGuards and skip handleConnection, an unauthenticated client can still open a socket and sit idle in your server.

  • Use handleConnection to reject unauthenticated sockets at the door.
  • Use event guards for fine-grained, per-action authorization.

The two layers complement each other: one controls entry, the other controls actions.

Surfacing Errors Cleanly to Clients

When a guard throws WsException, NestJS emits an exception event to that client instead of crashing the connection. Add a WsExceptionFilter to shape the payload so the frontend gets a predictable error object it can show to the user.

import { ArgumentsHost, Catch } from '@nestjs/common';
import { BaseWsExceptionFilter, WsException } from '@nestjs/websockets';
import { Socket } from 'socket.io';

@Catch(WsException)
export class WsErrorFilter extends BaseWsExceptionFilter {
  catch(exception: WsException, host: ArgumentsHost) {
    const client = host.switchToWs().getClient<Socket>();
    client.emit('error', {
      message: exception.getError(),
      timestamp: new Date().toISOString(),
    });
  }
}

Handling Token Expiry on a Live Socket

A connection authenticated an hour ago may now hold an expired token. Two common strategies:

  • Re-verify per sensitive event — store the raw token on client.data.token and call verifyAsync again inside the guard for high-value actions.
  • Periodic revalidation — a server interval checks each socket's token exp and disconnects expired ones.

This small pure function shows the expiry check at the heart of either approach.

interface TokenInfo {
  exp: number; // unix seconds
}

function isExpired(token: TokenInfo, nowSeconds: number): boolean {
  return token.exp <= nowSeconds;
}

const now = 1_700_000_000;
console.log(isExpired({ exp: 1_699_999_000 }, now)); // true  -> disconnect
console.log(isExpired({ exp: 1_700_500_000 }, now)); // false -> keep open

Wiring It Together in the Module

Guards that inject services like Reflector or JwtService must be resolvable by Nest's DI. Because the gateway and its guards live in the same module, register JwtModule and provide the gateway; the guards are instantiated by Nest when referenced in @UseGuards.

You can also register the auth guard globally for sockets with APP_GUARD if every event should be authenticated by default.

import { Module } from '@nestjs/common';
import { JwtModule } from '@nestjs/jwt';
import { APP_GUARD } from '@nestjs/core';
import { ChatGateway } from './chat.gateway';
import { WsAuthGuard } from './ws-auth.guard';

@Module({
  imports: [
    JwtModule.register({ secret: process.env.JWT_SECRET }),
  ],
  providers: [
    ChatGateway,
    { provide: APP_GUARD, useClass: WsAuthGuard },
  ],
})
export class RealtimeModule {}

Quick Check: Connection vs Event Auth

You want to (1) block unauthenticated clients from ever opening a socket and (2) allow only admin users to emit a broadcast event. Which combination correctly achieves both?

Recap: Securing Realtime Connections

You now have a complete, layered approach to securing NestJS WebSocket gateways:

  • Extract the token consistently from handshake.auth, headers, or query.
  • Authenticate at the door in handleConnection, disconnecting invalid clients and attaching the user to client.data.
  • Authorize per event with guards that switch to the ws context, including role checks via Reflector and a @WsRoles decorator.
  • Report errors through a WsException filter, and handle expiry with re-verification or periodic checks.

Connection auth controls entry; event guards control actions — together they keep your realtime system secure.

常见问题解答

「验证并保护 Socket 连接」课时是免费的吗？

是的 — 「验证并保护 Socket 连接」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 NestJS Enterprise Backend APIs 课程的其余内容，请升级到 CoddyKit PRO。 NestJS Enterprise Backend APIs 课程共包含 4 节课。

「验证并保护 Socket 连接」这节课中我会学到什么？

对握手和消息事件执行守卫与令牌验证，以实现安全的实时访问。 你通过在浏览器中直接运行的动手代码来练习 NestJS Enterprise Backend APIs，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 NestJS Enterprise Backend APIs 需要有经验吗？

无需任何先前经验。CoddyKit 上的 NestJS Enterprise Backend APIs 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 2 节课，共 4 节。

「验证并保护 Socket 连接」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 NestJS Enterprise Backend APIs 课中编写并运行代码吗？

能。每节 NestJS Enterprise Backend APIs 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. 使用 Socket.IO 适配器构建 WebSocket 网关
  2. 验证并保护 Socket 连接
  3. 用于单向推送的服务器发送事件
  4. 使用 Redis 发布/订阅适配器扩展实时能力
← 返回 NestJS Enterprise Backend APIs