Support LiveView

[frm]

We're currently not supporting any type of authorisation for LiveView.

Should we add a plug that makes use of conn.private[:phoenix_live_view] and calls certain policies?

What about inferring the action and resource? How could that be achieved?

Should we add a new Dictator.Policies.LiveView module since it will essentially be a different type of policy?

[naps62]

I guess what we need here is a way to distinguish between multiple types of requests. We only considered regular REST requests, but there's also websockets (which LiveView is a subset of), and also graphql

There's two decision there, I think.
First, how do you decouple from conn. One approach could be have multiple strategies in place

defmodule MyApp.Web.Router do
  scope :api do
    use Dictator, strategy: Dictator.Strategies.Rest
  end

  scope :graphql do
    use Dictator, strategy: Dictator.Strategies.Graphql
  end
end

(just pseudo-code, not sure if that syntax would even work)

Or you can just ignore all that, and somehow try to guess the action & resource for every single type of request. Which, at least at face value, I don't particularly like, for 2 reasons:

• It sounds more magical, which I don't think is very Elixir'y
• I'm not even sure how that would work for GraphQL, where you do multiple different requests in a single HTTP request. You can only make that decision further down the road, when processing each individual part

The second decision is how to ask for permissions to each of them. Here I think we can even allow both options, because of pattern matching:

defmodule MyPolicy do
  # this could work for both a Rest endpoint, or a LiveView request
  def can?(:show, _, _), do: true

  # or people can prefer to segregate both for some reason:
  def can?({:rest, :show}, _, _), do: true
  def can?({:live, :show}, _, _), do: true
  def can?({:graphql, :show}, _, _), do: true

[frm]

You make a very good point.

somehow try to guess the action & resource for every single type of request

I agree with your reasons, I don't think that is the correct way to approach it.

One approach could be have multiple strategies in place

I like this idea, but I'm getting concerned with so many configuration options. It's becoming too verbose IMO. How about plug Dictator.LiveView and Dictator.GraphQL? We would default Dictator to REST APIs since these are the most common.

Here I think we can even allow both options, because of pattern matching:

I don't like that pattern visually. It's starting to get too verbose. We know that for REST requests, we can use the action to pattern match. For live view, I think at most we have the path, so we can go with that:

defmodule MyPolicy do
  def can?(:show, _, _), do: true
  def can?("live/path", _, _), do: true
end

Ideally we would suggest a policy explicit for LiveView, so that these wouldn't mix up but that doesn't look too bad does it?

I don't know how it would work for GraphQL

[naps62]

Dictator.LiveView and Dictator.GraphQL

I like this approach. assuming it's feasible. I can't picture right away how this would work

One question though. Would it be Dictator.LiveView or Dictator.PhoenixChannels? are there differences between the two?

[frm]

I think LiveView adds a few conn.private keys we can leverage.