miguelcoba
Hi there, I would like to know your thoughts about how to use Oban workers in a Phoenix app with Scopes.
When using scopes the context functions receive as first parameter the scope, f.e.
# lib/my_app/blog.ex
def list_posts(%Scope{} = scope) do
Repo.all(from post in Post, where: post.user_id == ^scope.user.id)
end
If I needed to use the list_posts inside a worker, I’ll need somehow to build a scope in order to use those scoped functions:
defmodule MyApp.MyWorker do
use Oban.Worker
@impl Oban.Worker
def perform(%Oban.Job{args: %{"id" => id}}) do
scope = # ? how to get the scope at the time the worker runs
list = Blog.list_posts(scope)
# Do something with list
:ok
end
end
Option 1.
Pass the scope (or enought data to rebuild the scope) as params to `Worker.new()`
%{user_id: scope.user.id, other: "data"}
|> MyApp.Worker.new()
|> Oban.insert()
and in the worker use user_id to build a `scope` and continue from that.
Option 2.
Add additional heads in the Context that don’t require scope and are only used by trusted callers (in this case Oban)
# lib/my_app/blog.ex
# additional function head that does not use scope
def list_posts(user_id) do
Repo.all(from post in Post, where: post.user_id == ^user_id)
end
defmodule MyApp.MyWorker do
use Oban.Worker
@impl Oban.Worker
def perform(%Oban.Job{args: %{"id" => user_id}}) do
# use the non-scoped functions
list = Blog.list_posts(user_id)
# Do something with list
:ok
end
end
None of the options is optimal, but from those two, the option 2 is the worst as it totally breaks the idea of scopes in the context modules by allowing anyone to bypass the scoped functions and use the non-scoped ones.
So I’m leaning on passing enough info to the worker params and use that to build a scope inside it and then use it to do whatever thing the worker needs to do using the scoped context functions.
Is there another way?
Do you have suggestions/ideas/experience implementing something like this?
Thanks in advance,
Miguel Cobá
Where Next?
Trending in Questions
Other Trending Topics
Latest Oban Threads
Latest on Elixir Forum
Sponsor Spotlight
Deploy Phoenix to your own VPS with PaaS ease: push-to-deploy, zero downtime, auto SSL, managed Postgres. 14-day free trial at potions.io
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
pjode
I think it depends on the type of worker. If the job being run is a deferred action a user is making that should be run in the scope of a user, putting the data necessary to reconstruct a user scope in the job is the right choice IMO. If the job is something that executes in a more privileged way, I actually define a new scope for that. For example, I have a scope defined for ingest and use that in function heads instead of a user scope. So you could imagine something like
and again you’d store what you need in the job to construct such a scope. This way functions still expect some form of scope regardless.
slouchpie
Maybe put the
user_idas an entry in the job’sargsand then use theScope.for_userfunction (or whatever equivalent you have for this)?tfwright
I’m not sure why you think this. Scopes are usually applied to user input at the edges (e.g. to request params) so unless you are allowing users to directly pass args into Oban jobs most likely those params should have already been scoped and so can be considered safe.
Also, it seems that Phoenix or Oban don’t really matter here. This question kind of reminds me of ones you would occasionally see on here a few years back about “how to use contexts in phoenix.” Contexts only “exist” in Phoenix as a pattern in the generators/ecosystem. They don’t have an API you need to (or can) use to accomplish x, y or z in any particular way. They are just modules.
Similarly, “phoenix scopes” are just structs that phoenix will generate for you according to a conventional naming scheme. They exist as a concept in generators, and the docs, it seems mostly to promote good programming practices. As the docs say:
rhcarvalho
One counter argument to this is if user permissions change between scheduling the job and running the job, one probably wants to check authorization when the job starts (or the user could have been deleted, banned, etc).
Similar to how
handle_eventand others should check before performing an action, as the system may have changed since themount.tfwright
My point was that this is all just business logic, so yeah. There is no “idea of scopes” that can be violated in this way. Usually validating at the edges is fine but depending on the specific requirements of the app/business it might not be. Even if you need to care about permission changes (it might even be the case roles/access are immutable!), it can also go the other way, that you need to respect what they were at the time of the request, or it might be necessary to raise a more specific error, etc etc. Checking on mount in a LV may very well be acceptable or exactly what’s required. I don’t think there is any general rule for any of this, and so there is no utility that Phoenix can/does provide that you can use to ensure you are using scopes “the correct way,” it’s just a nudge to start with a basic pattern in place.
miguelcoba
yeah, most of the times is something simple like that. Imagine an email that is send as a side effect of some UI action that I don’t want to do it in the same request as the UI, but still it needs to access the user info.
I guess that’s a valid option even if the explode of scope < - > rebuild of scope hits me like an extreme middle step.
Thanks for your perspective.
miguelcoba
yes, that’s exactly what I’m currently doing, but it looked weird to me that I needed to extract that into params, then on the other side, rebuild a scope just in order to be able to use the scoped functions.
As it looks, it seems that’s unavoidable and the way to go.
Thanks, James!
miguelcoba
Interesting. I was trying to follow the docs and use the scope to harden/validate access to data. I didn’t even consider to break that “contract” as it seemed to me like diverging of the “good practices”. Maybe I should relax my view and view unscoped functions that are called from places where validation has already happened and it is safe to do so, is ok.
Yeah, maybe I’m reading too much and assigning too much weight to them and that introduces unflexibility
I’ll take a good thinking on this.
Thank you!
miguelcoba
Interesting. So far I have not paid attention to that. In the oban side I just executed the action enqueued. I assumed if the job was scheduled is because on the scheduling function, validation was already performed and I didn’t want to repeat that. Maybe I should reconsider that.
Thanks, this is helpful!
miguelcoba
I like that. Definitely changes the way we approach programming with scopes. I’ll keep it in mind.