Is auth context passed to scheduled actions from server side queries/mutations?
I'm calling an action within a server side mutation using:
However when trying to retrieve the userIdentity within the action via:
It returns null.
Is the auth context only passed to the action when the action is called directly from the client? Or am I doing something wrong? I'm using Convex Auth btw.
7 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!
correct https://docs.convex.dev/scheduling/scheduled-functions#auth
the idea is that the function might run later, so the user might no longer be authenticated
thanks @Lee. Maybe it would be good to link to that from the docs on Function/actions + internal fns
Hey @lee , this prevents reusing queries/mutations that rely on the auth. Is there a ways to SET the current user? Then at least we could restore the auth context in the scheduled action
I guess this is the way to go:
- only runQuery / runX / schedule internal functions
- auth checks in public functions
- no auth checks in helpers
see: https://docs.convex.dev/understanding/best-practices/#only-schedule-and-ctxrun-internal-functions
If you have code you want to share between a public Convex function and an internal Convex function, create a helper function that can be called from both. The public function will likely have additional access control checks.
Best Practices | Convex Developer Hub
Essential best practices for building scalable Convex applications including database queries, function organization, validation, and security.
yeah, that's what I figured, thanks. But it's really annoying having it globally on the context and then it's just "randomly" empty...
You can pass authorization data (like an authorized user id) through args for scheduled functions