How to scope resources to user?

I have implemented user handling with the built-in phx.gen.auth solution and now created a resource that is in one-to-many relationship to the users (i.e. one user may have one or more resources).

What would be the most elegant and standard way to limit access to the resources in a way so that a user only see/change her own resources and also, whenever a resource is created/updated, it is automatically assigned to the user?

1 Like

The most elegant? Let the database handle it using Row Level Security. Otherwise you need to use the user identifier in every query you want to scope.

1 Like

I’m more looking for something that can be easily plugged into Phoenix, maybe a plug or a library, but authorization libraries seem to be too complex for just this purpose.

For the time being, I’m adding the user identifier to all model queries in the controller, not sure if this is the ideal approach.

The “standard approach” is to create a Context module to hold your functions for a particular context (e.g. Resources), and then write Ecto queries the same way you would write SQL (the Ecto syntax is essentially just SQL, which is what makes it so great).

Since you’ve already used phx.gen.auth you have a very good example of a Context (the Accounts context). You can create another context (they’re just modules, see the guide I linked) for your purpose, for example something like this:

defmodule MyApp.Resources do
  alias MyApp.Accounts.User
  alias MyApp.Resources.Resource

  def list_resources(%User{} = user) do
    Repo.all(from r in Resource, where: r.user_id == ^user.id)
  end
end

Where a Resource is an Ecto schema with a belongs_to relationship to your User schema.

This is perfectly fine - it’s the standard way to do things with a relational database. You should call out to the Context instead of writing your queries in the Controller, but that’s really just to keep your project organized as it grows (the time will come when you want to use a Context function from more than one Controller, for example).

You can also check out the Ecto multi-tenancy with foreign keys guide for a way to standardize this, but your particular use case might not be siloed well enough for this to be the right approach. I’d recommend scoping each query by hand for now.

2 Likes