ACL that requires multiple sids

[DangerDawson]

I have a requirement where I need an allow to take multiple sids to be present e.g. you need to be a member of 2 groups to approve a change (the change impacts items of both groups)

I can concatenate the sids in the allow as below

e.g. acl.allow "[group:1,group:2]"

Is this the approach you have taken?

[maximgurin]

I had a similar situation in my app. Ended up solving it the following way:

[group_1, group_2].each do |group|
  authorizer.authorize(current_user, group, :write)
end

An approach with SIDs concatenation can work, but it's fragile. E.g. a user has 2 required groups + 1 more. Or an order of groups could be different. This kind of use-case is better handled on a level above ACL.

[DangerDawson]

Thanks for the quick reply.

That makes sense, although if I wanted to use scope with this complexity I am guessing that I would need to build that into the where clause?

[maximgurin]

Yeah, with this complexity, I guess an additional where clause is inevitable. But in general, I'd recommend storing ACL in the database only for read operations. The point is to get a straightforward way to find all records (from a large volume of them) accessible by any given user.

You mentioned that your use-case is related to changing the records, not reading them. Changes are typically more narrow (a few records), so authorization in the app layer instead of the DB is simpler. Unless you have some strong additional reasons to rely specifically on DB queries.

[DangerDawson]

So a bit more context, we have a system where a change can get staged for approval by another user with the correct privileges e.g.

If we take a change where a Item has been added to multiple lists and Lists can belong to different Groups of which have a many-to-many relationship with Users.

A situation can arise where a user can add an item to multiple lists which are in different groups, and the only users that can approve the change are users which have a admin role of both groups.

And we would want to show a paginated index page of all theses changes.

So either we have to model this as multiple sids which could be brittle as you mentioned, or we would need to use a custom where clause.

BTW. I am super interested how you get on with your Hanami 2.0 project. We have used dry-effect to provide a scoping data e.g. a list of named scopes (methods) and would be happy to share approaches.

[maximgurin]

Yeah, I see now with an additional context. Probably a custom where clause is a more robust solution for such a tricky situation.

Regarding the scoping for Hanami 2, I've taken a simple approach. Defined a base class for all repositories and a scope method in it (accepts user as an argument). I bet your approach with effects is nicer, don't you mind sharing a snippet? :)

[DangerDawson]

So we are re-evaluating the way we are using dry-effect, as it is swallowing up our backtraces when an exception is being thrown:
But for your curiosity we approached it this way:

class ScopedRepo
  def call(repo:, required_scope:)
    Proxy.new(repo, required_scope)
  end

  class Proxy
    include Dry::Effects::Handler.Reader(:required_scope)

    def initialize(repo, required_scope)
      @repo = repo
      @required_scope = required_scope
    end

    private

    attr_reader :repo, :required_scope, :organisation_id

    def method_missing(method, *args, **kwargs)
      super unless repo.respond_to?(method, true)

      with_required_scope(required_scope) do
        repo.send(method, *args, **kwargs)
      end
    end

    def respond_to_missing?(method, include_private = true)
      repo.respond_to?(method, include_private)
    end
  end
end

[maximgurin]

Looks interesting, thank you for sharing. Especially if the backtrace issue could be resolved somehow.

[DangerDawson]

So you can do so, by setting a dry-effect at the rack level, which will wrap all the inner dry-effects

require 'dry/effects'

class RootDryEffect
  include Dry::Effects::Handler.State(:root)
  def initialize(app)
    @app = app
  end

  def call(env)
    _, response = with_root({}) do
      @app.call(env)
    end
    response
  end
end