Protecting link-creation functions as well as resource controllers

[marick]

It’s straightforward and slick to prevent users from being able to reach controllers for resources they’re not authorized for. For example:

  # Controllers that require Admin permissions.
  scope "/", Eecrit do
    pipe_through [:browser, :require_login, :require_admin]

    resources "/animals", OldAnimalController
    resources "/procedures", OldProcedureController
    resources "/procedure_descriptions", OldProcedureDescriptionController
  end

  # Controllers that require superuser permissions.
  scope "/", Eecrit do
    pipe_through [:browser, :require_login, :require_superuser]

    resources "/users", UserController
    resources "/ability_groups", AbilityGroupController
    resources "/organizations", OrganizationController
  end

However, it’s not enough to “lock the door”: you also don’t want unauthorized users to even see the door. For example, consider this control panel for a superuser:

Admins shouldn’t see the bottom three buttons. The way I’m doing that now is via this View function:

  def commands(conn, current_user) do
    raw_builder do
      unless current_user do
        build_commands([{"Please log in", session_path(conn, :new)}])
      end
      
      if empowered?(current_user, :is_admin) do
        build_commands([{"Work With Animals", old_animal_path(conn, :index)},
                        {"Work With Procedures", old_procedure_path(conn, :index)}])
      end

      if empowered?(current_user, :is_superuser) do 
        build_commands([{"Users", user_path(conn, :index)},
                        {"Organizations", organization_path(conn, :index)},
                        {"Ability Groups", ability_group_path(conn, :index)}])
      end 
    end
  end

(I’m using webassembly to construct a “partial” in code rather than in an eex template.) This works, but it’s not automatic in the way that using plugs is. That is, whenever I create a resource, the structure of router.ex forces me to choose its level of authorization. Everything works from there without any effort from me. But whenever I create a link to a resource, I ought to think “given the resource and the current user’s authorization, should I even generate the link?” I’d rather have that thinking happen automatically: if I ask for a link to a resource, I get either it or nil (so that nothing shows in the output).

(I know that “link or nothing” won’t necessarily be the right thing for all places in the UI, but it would be enough in the cases I’ve got or currently foresee.)

So what I’d like would be something where my mix phoenix.gen.html task would generate a model with an attribute like this:

defmodule Eecrit.OldAnimal do
  use Eecrit.Web, :model
  @requires_ability :inaccessible_until_you_change_this
  ...

… and then both plugs and link-constructing functions would key off of it. But I’m having trouble seeing how the plumbing would work.

So I’d be interested if anyone’s done anything like this, if there are libraries that help with this, etc. Thanks.

(I know about canada/canary, but I don’t see how to use them to implement the “tag the resource and everything else is done for you”. Slight reluctance to clump all resource permissions in one defimpl for User, but I guess a default “user can do nothing” has the necessary effect of forcing you to edit the file.)

(As you might tell, when it comes to security, I’m of the “any human failure [especially to act] fails safe” school.)

[OvermindDL1]

Greets, I’ve talked about this on the forums before (who knows where), but these are things that I’m currently using (might make a good first blog post…).

My permission system is more fine grained, for example someone may have access to a “/users/42” but not to a “/users/68” path, specifically based on what is being accessed and how they are accessing it (for example they could see “/users/42” but not be able to access “/users/42/edit”). I do use canada for the basic wrapping but it is fairly in consequential and could be done without it easily enough.

An example, here is one of my simple Index function:

  def index(conn, %{"sid" => sid_param} = _params) do
    happy_path!(else: handle_error(conn)) do
      @perm true = conn |> can?(index(%Perms.Student.Semester{}))
      {:ok, {_cnum, uid, _obj, _student}} = verify_student(sid_param)
      @perm true = conn |> can?(index(%Perms.Student.Semester{uid: uid}))
      students_semesters = Repo.all(from Student.Semester, preload: [:semester])
      render(conn, :index, students_semesters: students_semesters, sid: sid_param)
    end
  end

So as you can see I do permissions in-line (all tagged with @perm at the beginning, which makes it easy to grep too).

But here I first check that they have access to the :index action on the given permission, then I check that they have access to the same thing but for the specific user. If this fails then it will redirect to a login page advising them that they need to login with an account that has that permission.

However, you were wondering how one might adjust listed menu’s given a persons access to an area. I have precisely that as well. The top header on the site has a dynamically created ‘Module’ dropdown along with a secondary action dropdown that is either there or not based on if the section the person is in has one or not.

Found an old image showing it: https://overminddl1.com/screenshots/work/MenuDemo.gif

The Module dropdown in my template is something like:

<%= render_accessible_modules @conn, assigns, loc %>

And that function is:

  def render_accessible_modules(conn, assigns, loc) do
    MyServer.ModuleLoader.get_all_modules()
    |> Enum.sort
    |> Enum.map(fn module ->
      module.menu(conn)
    end)
    |> List.flatten
    |> case do
      [] -> []
      modules -> {:dropdown, gettext("Modules"), modules}
    end
    |> render_module_specific_menu(conn, assigns, loc)
  end

So I ask the ModuleLoader for all modules that exist in the system, calling their requisite menu callbacks (as required by their behaviour), concat them all together and make it into a :dropdown in my simplified dynamic html’ish system (done because it is easy to serialize out, unlike eex, but eex could be used too, and this is then generated into eex). The result of that is then rendered by render_module_specific_menu/3, which is just a fairly stock eex template that does the bootstrap wrapping stuff.

The part that determines access or not is the module.menu(conn) call, let’s look at one of those from one of my modules, how about the admin module with extra stuff removed:

defmodule MyServer.Routers.Auth do

  use MyServer.ModuleBehaviour

  def menu(conn) do
    happy_path(else: handle_noauth) do
      @perm true = conn |> can?(index(%Perms.Auth{}))
      {:link, [:module, :auth], gettext("Admin"), MyServer.Router.Helpers.auth_path(conn, :index)}
    end
  end

  # Snip other stuff
end

It has the same type of code as the controllers, just asking if the current user has ‘index’ action access to the given permission, if they do not it will return just (via my handle_noauth/1 function, I need to clean that up), else it returns the next line. Could of course do fine permission testing for various things too but the basic menu links are simple.

The secondary menu follows the same path as the modules but only asks the given module if they have one, of the admin one is like:

  def breadcrumb(_conn, _assigns, MyServer.AuthView, "index." <> _)         ,do: [:module, :auth, :index]
  def breadcrumb(_conn, _assigns, MyServer.Auth.UsersView, _template)       ,do: [:module, :auth, :users]
  def breadcrumb(_conn, _assigns, MyServer.Auth.PermissionsView, _template) ,do: [:module, :auth, :users]
  def breadcrumb(_conn, _assigns, _view_module, _template)                   ,do: [:module, :auth]


  def action_menu(conn, assigns, _view_module, _template), do: {:dropdown, gettext("Admin"), [
    {:link, breadcrumb(conn, assigns, MyServer.AuthView, "index."), gettext("Admin Home"), auth_path(conn, :index)},
    {:link, breadcrumb(conn, assigns, MyServer.Auth.UsersView, "index."), gettext("User Search"), users_path(conn, :index)},
    ]}

So the action_menu/4 returns whatever it wants, a link, a dropdown menu, whatever, and that becomes the action menu for that module. The breadcrumb things handle the highlighting of the relevent sections based on where the user currently is at (so if they are in the UsersView then that will be highlighted and so forth).

It is simple, it could not doubt be vastly improved, a library of this style could probably be made pretty easily, and I have a lot of caching in the back-end for permissions and such that make it blazing fast.

Adding it to a Model/Schema would not be terribly useful for me as many of my sections are not backed by a model (but rather backed by LDAP or other system calls).

My permissions are defined like this, here is the above basic Admin permission (though I have others for other details too):

defmodule MyServer.Perms.Auth do
  @behaviour MyServer.PermsBehaviour
  defstruct action: nil

  def get_as_new(), do: %CCCServer.Perms.Auth{action: ""}
end

It is a very simple struct, it is backed by and stored into a database in a permission tree. For example a permission of:

perm = %Perms.Auth{action: :index}

Can be satisfied by any of the following:

:_
true
"_"
%Perms.Auth{action: :index}
%Perms.Auth{action: [:any, :index, :update, :edit, :show]}
%Perms.Auth{action: :_}
%Perms.Auth{action: "_"}

And a few others, all documented at PermissionEx — permission_ex v0.6.0 for more details.

But it gives me the fine-grained permission system that I need so I enjoy it.

[benwilson512]

@marick

def commands(conn, current_user) do
    raw_builder do
      unless current_user do
        build_commands([{"Please log in", session_path(conn, :new)}])
      end
      
      if empowered?(current_user, :is_admin) do
        build_commands([{"Work With Animals", old_animal_path(conn, :index)},
                        {"Work With Procedures", old_procedure_path(conn, :index)}])
      end

      if empowered?(current_user, :is_superuser) do 
        build_commands([{"Users", user_path(conn, :index)},
                        {"Organizations", organization_path(conn, :index)},
                        {"Ability Groups", ability_group_path(conn, :index)}])
      end 
    end
  end

Side note, really not a fan of this code block / dsl. How is it even supposed to work? It reads like it’s mutating something but it isn’t clear what that is or could even be. If if empowered?(current_user, :is_superuser) is false, the whole thing should just be nil because there’s no else block.

[marick]

Looks nice. I’ll definitely make some stabs at evolving in this direction.

[marick]

The stateful style bugs me too. But: the structure is really the same as a corresponding .eex template, just with easier syntax. And the better composability of functions vs. template partials tips me over the edge.

[marick]

Actually, now that I’ve realized that rendering produces iolists rather than strings, it looks like plain nesting works better:

  def wrap_in_section(iolist) when length(iolist) == 0, do: []
  def wrap_in_section(iolist) do
    [tag(:hr),
     content_tag(:p, iolist, class: "lead")]
  end

It’s looking like, with the aid of macros, bare Phoenix gives me a nicely readable way to express my intention while staying strictly functional. This is pretty sweet.