Comments (4)
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
from dictator.
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
from dictator.
Dictator.LiveView
andDictator.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?
from dictator.
I think LiveView adds a few conn.private
keys we can leverage.
from dictator.
Related Issues (10)
- Comparison with similar libraries (canada, bodyguard, etc). HOT 1
- Implement optional only/except arguments for plug, to whitelist/blacklist actions
- Update documentation HOT 1
- Wrong key for Ecto.Repo in the config files
- Add view helpers HOT 10
- Add a handler for resources not found HOT 2
- Allow the unauthorised handler to be configured when plugged HOT 5
- Support GraphQL HOT 1
- Fix test suite check annotations HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dictator.