smon
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.exand replaceform_component.ex. But then I can not use it inside a modal (?). This way I could set authorization in myrouter.ex. - Add a check in the relevant
apply_action/3inindex.exand use the same pattern inshow.ex? - Add checks to both existing live views:
.modal :if={@live_action in [:new, :edit] and @current_user}in the heex? - Pass the
:current_userto 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?
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
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
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
The modals in the default boilerplate have separate routes. Add authorization to those.
smon
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
:indexroute (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 nomountcall anymore and there is no second evaluation happening.LostKobrakai
You could switch the patch to be a proper redirect. More expensive on resoure loading, but giving you another mount.
smon
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.
codeanpeace
Definitely ensure that the
handle_eventcallback for the form submission/save event checks for authorization – in your case, that the user is registered.Events Consideration | LiveView Security considerations
krasenyp
I’d hide all the actions which the current user can’t perform.