marick
Protecting link-creation functions as well as resource controllers
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.)
Most Liked
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
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.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex










