How would you implement authorization on a form modal?

Phoenix Forum Chat / Discussions
,
1

Let’s me start out with a new project based on generators:

Using mix phx.gen.live gives me form_component.ex, index.ex and show.ex for my schema. The latter two use the form_component.ex as a modal:

<.modal :if={@live_action in [:new, :edit]} id="project-modal" show on_cancel={JS.patch(~p"/projects")}>
  <.live_component
    module={DemoWeb.User.FormComponent}
    id={@user.id || :new}
    title={@page_title}
    action={@live_action}
    project={@user}
    patch={~p"/userss"}
  />
</.modal>

or

<.modal :if={@live_action == :edit} id="project-modal" show on_cancel={JS.patch(~p"/projects/#{@project}")}>
  <.live_component
    module={DemoWeb.ProjectLive.FormComponent}
    id={@project.id}
    title={@page_title}
    action={@live_action}
    project={@project}
    patch={~p"/projects/#{@project}"}
  />
</.modal>

Now I am having a look at mix phx.gen.auth and was wondering how I could restrict only the modal usage (both :new and :edit) to registered users.

Ideas so far:

  • Create a standalone live view form.ex and replace form_component.ex. But then I can not use it inside a modal (?). This way I could set authorization in my router.ex.
  • Add a check in the relevant apply_action/3 in index.ex and use the same pattern in show.ex?
  • Add checks to both existing live views: .modal :if={@live_action in [:new, :edit] and @current_user} in the heex?
  • Pass the :current_user to the live component and let the live component handle the check?

I would prefer to handle this in the router.ex, just because then all restriction related logic would be defined at one point.

Any other ideas?

2

The modals in the default boilerplate have separate routes. Add authorization to those.

3

How would you do that from the router?

The generated authentication logic seems only to check “on_mount” for live views and the initial “dead view” requests. If a guest user is on the :index route (i.e. successfully mounts the view) and then switches to the edit route which is supposed to be restricted, they still use the same live view process, there is no mount call anymore and there is no second evaluation happening.

4

You could switch the patch to be a proper redirect. More expensive on resoure loading, but giving you another mount.

5

Ah, right - the patching in my links was what confused me.

Instead of switching all patches to redirect I would simply render those links only if current_user is set? I am still struggling to evaluate where I might run into security issues with the LiveView Javascript magic.

6

Definitely ensure that the handle_event callback for the form submission/save event checks for authorization – in your case, that the user is registered.

Every time the user performs an action on your system, you should verify if the user is authorized to do so, regardless if you are using LiveViews or not. For example, imagine a user can see all projects in a web application, but they may not have permission to delete any of them. At the UI level, you handle this accordingly by not showing the delete button in the projects listing, but a savvy user can directly talk to the server and request a deletion anyway. For this reason, you must always verify permissions on the server.

In LiveView, most actions are handled by the handle_event callback. Therefore, you typically authorize the user within those callbacks. In the scenario just described, one might implement this:
…

Events Consideration | LiveView Security considerations

7

I’d hide all the actions which the current user can’t perform.