Protecting link-creation functions as well as resource controllers

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.

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.

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

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.

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.