I wonder if this would have been a better api Blog.get_post!(id, scope: socket.assigns.current_scope) with the scope being optional 
4 Likes
If you want to do that in your own code – sure! Remember the generators are a starting point, but the whole goal for scopes is to make secure data access the default and something that grows with your interfaces, so it’s not something phoenix should do out of the box.
4 Likes
They are just plain structs that your app wholly owns, so you can populate them with whatever you want!
I’m using the setup from this guide: Multi tenancy with foreign keys — Ecto v3.12.5. From what I understand, using scopes would simplify things by removing some of the plumbing from that guide.
Is it correct that if I use scopes, I don’t need to manually pass org_id around or store it with Process.put? Would scopes essentially handle that part for me automatically? Just want to make sure I’m thinking about this right.
1 Like
These approaches would be alternatives to each other. One using the process dict to implicitly retain the org context, or the scope struct to explicitly pass the org around. I wouldn’t call this “handle … for me automatically” though.
As a user of Surface who finds it really useful that the context/scope is automatically available in child components without having to include something like attr :current_scope, Scope, required: true and current_scope={@current_scope) everywhere, I had assumed that scopes would do something similar but is that not the case?
2 Likes
It does but we speak of that when already talking about the router. %Scope{} itself can be considered a Phoenix Context so if would be much more confusing for it to named Context.
We’ve been using Scope at work for months now and it’s never confusing which “scope” we are talking about. However, “take a look at the context” would be far more confusing.
No this is not the case. Scopes are just a struct that you can use to explicitly pass around “global” application data.
Wow! Congratulations to Chris and team.
So many good things here.
The decision to include DaisyUI is very welcome.
Scopes put the right foundation for multi-tenant/SASS apps.
Very nice. More power to you!
2 Likes
Congrats on the release! 
Small note: seems like a link with this text is broken 
Are there any details on how to opt-in? I cannot find out how to configure this option.
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.
2 Likes
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.
2 Likes
Sorry, this should have said remains opt-in via user settings. I’ve updated the post!
3 Likes
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.
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. 
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 Likes
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 Like
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]}}
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?
