Fiber Contrib

The Socket.io implementation supports both WebSocket and HTTP long-polling transports.

When working with a socket instance (kws), you must account for the fact that kws.Conn (the underlying FastHTTP connection) is nil when the session is bound to HTTP long-polling.

Best Practices:

1. Use Listener APIs: Methods like Emit, Ack, Close, Broadcast, and EmitWithAck are transport-agnostic and work correctly regardless of whether the client is using WebSockets or long-polling.
2. Guard Direct Access: If your code needs to touch the underlying WebSocket connection directly via kws.Conn, you must guard the operation to prevent nil pointer dereferences.

Use kws.IsPolling() to explicitly check if the session is currently using long-polling.

// Guarding direct connection access
if kws.Conn != nil {
    // Access underlying FastHTTP connection
} else {
    // Session is using HTTP long-polling
}

// Or checking transport type explicitly
if kws.IsPolling() {
    // Handle long-polling specific logic
}

The KeytabLookup field in spnego.Config expects a function that returns a *keytab.Keytab and an error. This allows you to fetch keytabs from databases, secrets managers, or remote services.

Important Performance Note: KeytabLookup is called on every request (authenticated or not). If your lookup involves network calls or database queries, you must cache the result and refresh it out-of-band (e.g., via a TTL or rotation event) to avoid adding significant latency to every request.

Security Warning: Do not return sensitive key material in the error returned by your lookup function. Errors are logged and passed to OnError. If you are reading a file, separate the file-reading error from the parsing error to avoid logging the key buffer.

// Example: Retrieve keytab from a database
func dbKeytabLookup() (*keytab.Keytab, error) {
    // Your database lookup logic here
    // ...
    return keytabFromDatabase, nil
}

// Example: Retrieve keytab from a remote service
func remoteKeytabLookup() (*keytab.Keytab, error) {
    // Your remote service call logic here
    // ...
    return keytabFromRemote, nil
}

CPULoadCriteria implements the LoadCriteria interface using CPU usage as the metric. It uses a proportional rejection probability model based on two thresholds:

• Below LowerThreshold: No requests are rejected.
• Between LowerThreshold and UpperThreshold: The probability of rejecting a request increases as CPU usage approaches the UpperThreshold. The probability is calculated as: rejectionProbability := (cpuUsage - LowerThreshold*100) / (UpperThreshold - LowerThreshold)
• Above UpperThreshold: All requests are rejected to prevent system overload.

CPULoadCriteria Properties

The JWT middleware enforces several security standards based on RFCs to prevent common vulnerabilities:

• Algorithm Pinning: The signing algorithm is determined by your configuration (SigningKey.JWTAlg), not the token itself. This prevents algorithm substitution attacks. You can also use jwt.WithValidMethods in ParserOptions to explicitly pin allowed algorithms.
• Refusal of alg: none: The middleware refuses tokens with alg: none and ignores header parameters like jwk, jku, x5u, and x5c to prevent key injection. To explicitly allow alg: none (not recommended), set SigningKey.Key to jwt.UnsafeAllowNoneSignatureType.
• Critical Header Check: It validates the crit header parameter per RFC 7515. Tokens with unknown critical parameters are rejected.
• Claim Validation: exp (expiration) and nbf (not before) are validated by default. You can use jwt.WithLeeway, jwt.WithExpirationRequired, or jwt.WithNotBeforeRequired in ParserOptions to adjust this. Use jwt.WithoutClaimsValidation() to disable validation entirely.
• Base64url Padding: By default, segments must be unpadded. Use jwt.WithPaddingAllowed() in ParserOptions to allow padded segments.