Remote IP address in queries/mutations/actions

[SuperJakov]

Some compliance and certification processes (such as audit logging or user tracing) require logging the remote IP address of the client making the request.

Currently, there doesn’t appear to be a built-in way to retrieve the client's IP address using the ctx object in Convex actions or functions.

Request:
It would be helpful if Convex provided a reliable and secure way to access the remote IP address of a request via ctx, so developers can log or use it as needed for auditing or security-related purposes.

Use case example:

export const someAction = action({
  args: { ... },
  handler: async (ctx, args) => {
    const ip = ctx.request?.ip; // Ideally something like this
    logToAuditTrail({ userId: ctx.user?.id, ip });
  },
});

Thank you for considering this!

[thomasballinger]

Agree this should be in. For httpActions, no problem: we already know the way to expose them, additional headers, something like X-Forwarded-For. Just prioritization, this coming.

For Actions, sometimes an action is scheduled doesn't have an IP associated with it; we could treat this similar to auth where it's your job to propagate it to a scheduled functions if you need it there. A little more design required, could be ctx.request or ctx.client or ctx.meta, I like ctx.request. Depending on the transport it might be a WebSocket, it might be an HTTP request, it might be scheduled; so you can't count on it being there, but yeah we can probably do this.

For mutations, same deal but it gets a bit tricky because mutations can retry, need to figure out which IP to use. Could always be the websocket connection in which the mutations was initially enqueued, not too bad?

For queries, this is a great way to make your query very unlikely to get cache hits. Maybe, but we're not starting with this. We'd need to track whether you accessed it. Doable stuff, doesnt' exist yet, not coming soon.

[nipunn1313]

See #132 for a community implementation. I think we probably want to hash out the design (per what @thomasballinger laid out) before committing to a solution here.

If I'm being honest, we probably won't have time to prioritize this right away - but it's definitely on our list.