This isn’t a code configuration option (I had assumed that). Once you’ve signed in, you can go to the account settings and opt-in there. From a code perspective you could of course just remove the magic link code which seems straightforward.
leejarvis
bdarla
If this is true, then the opt-in refers to the user and not the developer. I hope that (if this is true), it will change to give the option to the developer.
3
chrismccord
Creator of Phoenix
bdarla
Thanks for the clarification!
Moreover, I just noticed in the provided video the easy way to confirm the email by visiting the mailbox. It escaped my attention at first.
0
jam
That’s fair. I imagine there was a good reason why you chose to include scope first. Curious to learn the thinking there. As someone fairly new to elixir, I’m still learning best practices. 
0
CharlesIrvine
I know what I would like 2.0 (Phoenix/LiveView) to have: suitability for mobile deployment. I read in a post by @josevalim that LiveView wasn’t ready for mobile deployment. So, without really understanding why (and I still don’t), I’ve started my new mobile app development using:
- React Native
- Expo
- Firebase
- GlueStack.
What a convoluted, complex nightmare. I long for the beauty of Phoenix/LiveView.
2
sodapopcan
From having used this pattern for a long time now, having it as the first parameter codifies right in the signature that it’s required. If it’s optional, it’s clearer to make a separate head that takes the schema as the first parameter. Otherwise, having it as an option (scope: scope) means you need extra code to always grab it from options. This may not seem like much, but it means you’re always adding extra code to every function whether the option is required or not and testing against that.
Now, I’m not saying that having as an option is bad—Ash does this, but it’s not exactly a trivial implementation and has measures to make things clearer. For example, you can explicitly tell Ash that the actor (scope) is required for every function in an entire domain (context) in one line.
1
AlchemistCamp
I’m curious to understand a bit more what you had in mind. In the scopes guide, there’s a blog example that goes through the following three steps:
- run the auth generator
- run the live generator to create blog posts and add the routes to the router
- run the migration (which includes a reference to user_id thanks to step 1)
Now, the app has blog posts, but they’re locked down for every action. Let’s suppose the would be blog creator wants all site visitors to be able to read the blog posts instead of only the authors being able to read their own posts. Also they want visitors to be able to read blog posts without creating an account.
So, they’ll want to move the router line for live "/posts/:id", PostLive.Show, :show and probably live "/posts", PostLive.Index, :index out of the live_session that requires authenticated users.
However, when doing this, there will be no function clause matching errors for logged out users visiting /posts or /post/1, etc. After editing the context to resolve that, the Blog.get_post!/2 will fail.
In this case, the next steps might be something like…
- In the Blog context, add a function head to handle nil scopes
def subscribe_posts(nil), do: :ok - Do the same for
broadcast/2 - Make alternate versions of
get_postandlist_poststhat don’t include theuser_idin the query sent to Ecto.
Is this roughly the workflow you envision people using for something that needs to be more open than the new default?
Edit: I’m guessing the answer is probably not, since this means navigating across live_sessions to go from one Blog action to another (and doing full page reloads as a result).
The pattern I’ve used for times in the past when some actions for a schema require authenticated users and some don’t has been to put them all in the same live_session block in the router and then do the authorization from the mount function of individual live views using the LiveHelpers.assign_user/2 (from previous phx generators) to ensure authentication.
Is there a pattern in particular you’re hoping to steer people towards in this scenario now?
Additional Edit: How about this pattern for when only some actions in a LiveView require authentication?
In UserAuth, create a custom on_mount like this:
def on_mount({:require_authenticated_unless, allowed_actions}, _params, session, socket) do
socket = mount_current_scope(socket, session)
current_user = socket.assigns.current_scope && socket.assigns.current_scope.user
action_always_allowed = socket.assigns.live_action in allowed_actions
if current_user || action_always_allowed do
{:cont, socket}
else
socket =
socket
|> Phoenix.LiveView.put_flash(:error, "You must log in to access this page.")
|> Phoenix.LiveView.redirect(to: ~p"/users/log-in")
{:halt, socket}
end
end
Then in any LiveView where it’s needed, use the custom on_mount hook to open specific actions (while still requiring authentication for all others)?
on_mount {AppWeb.UserAuth, {:require_authenticated_unless, [:show]}}
3
terenceponce
Congratulations on the release! I have a question about scopes.
I’m looking at the documentation for Scopes and I was wondering about the test_data_fixture option for defining scopes. It looks like a required option, but what should I do with this if I’m using factories (ex_machina) instead of fixtures?
0
mgibowski
Define a module with fixture functions that wrap factories, like:
def user_scope_fixture do
insert(:user)
end
1