Conversation
| console.log('Initializing Cap\'n Web connection...'); | ||
|
|
||
| // Create WebSocket connection | ||
| const wsUrl = `ws://${window.location.host}`; |
There was a problem hiding this comment.
Why are we using ws:// unconditionally? Could it be replaced with the following approach?
Choose protocol based on window.location.protocol, e.g.:
const wsProtocol = window.location.protocol === 'https:' ? 'wss' : 'ws';
const wsUrl = ${wsProtocol}://${window.location.host};
As browsers might block the connection on secure origins and the RPC client might fail.
| const config = { | ||
| auth0: { | ||
| domain: AUTH0_DOMAIN, | ||
| clientId: process.env.AUTH0_CLIENT_ID, |
There was a problem hiding this comment.
Problem:
/api/config may return a 500 when AUTH0_CLIENT_ID is missing because startup only validates AUTH0_DOMAIN/AUDIENCE.
Possible Fix:
By Failing fast on startup (or return a clear JSON error).
Add AUTH0_CLIENT_ID validation at boot so the server never runs with an incomplete public config.
| server, | ||
| verifyClient: (info) => { | ||
| console.log('WebSocket connection request from:', info.origin); | ||
| return true; // Allow all connections for development |
There was a problem hiding this comment.
Problem: verifyClient returns true for all origins/connections. Accepting all WS connections without initial authentication could be insecure.
This should be okay for demo, but for production, tighter handshake should be implemented (validate Origin and or require an Authorization token during the WebSocket upgrade or as the first RPC "authenticate" call), rejecting unauthorized upgrade attempts. As leaving the upgrade open is a security risk.
| id: message.id, | ||
| result: result | ||
| })); | ||
| } catch (error) { |
There was a problem hiding this comment.
We should not send raw internal error messages back to clients over WebSocket. As the server forwards error.message directly to the client. This can leak internal details (stack traces, validation internals).
We should sanitize error responses sent to clients. Send a safe, minimal message (e.g., "Invalid request" or "Invalid access token") and log full error details server-side for debugging. This should prevent leaking sensitive server internals and improve security posture.
2 participants
Added a Cap'n Web Sample to feature on an upcoming blog post.
More info: