How to get request.ip inside a convex server function?
The title:
This would be really nice
15 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
Not available currently. Relevant (especially if you're thinking about rate limiting): https://discord.com/channels/1019350475847499849/1203007687344914503/1203114033570644019
If you can share a bit more of your use case, maybe there's a different way
wanted to use it for stripe to add merchants into my platform. Stripe requires userAgent and ip to accept tos
Gotcha. cc/ @ballingt another valid use case for ip address exposure.
At the moment you'd either have to use one of Stripe's other approaches for adding merchants (I think there's an embedded option?), or use a more traditional serverless function provider (Vercel or Netlify would work if you're using either for your frontend) for this specific endpoint, which could then call back into your Convex api.
Yeah but I would like to keep users in app for everything, not redirect them to some web view, Ill look into other cloud providers for this use case even though it is not the most ideal solution
@AlphaOmega do you need this in mutations/queries/actions, or would it be enough to have it in an HTTP Action? An environment variable is the simplest API to add, probably not
ctx.request.ip for nowmutation would be preferred but I can work with an http action aswell
also do you need it in queries, or are mutations and actions good enough? It's more involved to add for queries because we want to be careful about invalidating the cache only when the ip address is accessed
I could also send it in the body but thats even less preferred
mutation in my case but I would urge the team to add it to queries aswell, as for cache and so on ip would be a key as any other items you caught outside the closure
or however youre catchin cache keys
yeah we'd only add it to the cache key if it was accessed but that requires a little more design. Something like a getter with a side effect on
ctx.meta.ip or proces.env.request_ipprocess.env.request_ip is the worst of this solutions
it feels un-intuitive
your proposal would be an new object on ctx, ctx.request? It's odd because a WebSocket connection can't have headers etc., it's not a request in the same way. But we could do
ctx.meta.requestIP or something, just a higher bar for adding things to ctxthat makes sense, ws dont have requests, but they do have a handshake, either way the name is of no issue, ctx.meta.ip is more than fine, it is derrived that it comes from the client
whose ip would it be
else than the clients
sometimes you want to know your outgoing ip when you make fetch() requests
i think for that purpose, a more explicit helper function perhaps
or yeah ctx.meta.requestIp and ctx.meta.ip
makes sense aswell