Thanks so much Tony for sharing your innovation with us through Fulcro. The experiments are cool, can't wait to try out the demos. Since fulcro-3.4.21-SNAPSHOT does not contain alpha.raw-components3.cljs, I have cloned the branch feature/fulcro-3.5 from the Fulcro repository. However, after spending hours trying to run the workspaces cards, I still haven't figured out the workflow to launch the workspaces (like the way we do it with Fulcro Template). It would be appreciated if anyone could give me a pointer on what is the best way to run these demo cards.

Shadow, build workspaces, then you have to use /workspaces.html on the non test url

http://localhost:9001/workspaces.html I think

Many thanks @U0CKQ19AQ for your help! The cards are working perfectly now.

Controls, just don't add it to the layout.

ok, I have added a control with :type :stringbut how do I set the value? This doesn’t work

ro/controls {:agency {:type :string :value "SYRCL"}}

this worked:

:componentDidMount (fn [this]
                        (control/set-parameter! this :agency "SYRCL"))

You can set it when routing to the report, the fn takes a map of extra params, look into the demo

Yes. It only works for CLJS. BUT. With fulcro itself, you can use components on the server-side as well. (for SSR or initial-state, for example). I figured, it would be nice to provide a cljc so that the user don't have to add reader conditionals in their code, if they wish to use their components on the server-side.

OK, that makes sense.

@U4VT24ZM3, I do have on more question, how do you turn this example:

<Typography variant="h6" color="inherit" noWrap className={classes.toolbarTitle} >

(material-ui.data-display/typography {:variant "h6" :color "inherit" :className "{classes.toolbarTitle}"}

{:noWrap true 
 :className "just-a-string"}

:className ["foo" "bar"] works as well.

{classes.toolbarTitle} is JSX syntax for string interpolation. The example you’re looking at must have an object called classes with a property toolbarTitle in scope somewhere.

@U6GFE9HS7, I believe the classes are generated by material UI, but I am not sure.

@U4VT24ZM3 I added that sample to your REAME.md, see if it makes sense to you. It may make it easier for someone like myself to get started. Also, I recommend removing the Warning statement from readme, warning reads to me that the repo can harm something, but it is pretty benign, clean, and nice repo, nothing to warn about.

classes comes from the custom styling method used in that material-ui example See: https://material-ui.com/styles/basics/#hook-api

The warning is there because I created the repo with no one in mind but myself. 🙂 Because of this not all components are included and there are some "breaking changes" (renames/moves).

What I’ve ended up doing in my projects is making defresolver/mutation macros that wrap pathoms, and allow the security declaration on the server pathom unit as a function that receives the pathom env and the inputs. That makes for a fully general permissions system where the middleware can augment the env with things like user permissions, policies, etc…and then the endpoint itself can look basically like this:

(defn admin-only [env input] ...)

(defresolver x [env input]
  {:policy admin-only
   ...})

Thanks for working on it. I look forward to seeing what you end up with. Integrating with the attributes is of course the right path, and having resolvers generate from defattr with a similar approach is, of course, pretty simple

Just looked through it some more. I would say: 1. The env has things like identity/session/ring request (if you add it), so that should be leveraged to do permissions/identity. 2. The input of the resolver/mutation tells you the “what” of the access So, the main feedback is essentially what I already gave you: I’d use a (fn [env input] ), where input for a read is assumed to be one of the ao/identities or possibly a sequence if you’re supporting batch.

and input is mutation params if it is a write…that perhaps makes it a bit tough. Forms can be composed in an arbitrary way. I agree with you that a partial auth failure on save should prob be treated as an attack and denied, but the fact remains that individual fields will have granular permissions, so for writes you really need to analyze things. For example, my write protections in my systems put an ownership link on every major entity (e.g. :item/owner _ref-to-acct-entity )_ which allows for the most important and common write permission check: “do you own it (or have write access to that other owner) already”? A write of something with a tempid needs the ownership added, and a write with a real ID need to be verified. This makes something like save-form! easy to augment, because that creates an easy-to-verify pattern in general

So, my form save auth middleware is pretty trivial, and general.

Thanks for the response. As for 1 above, my ad hoc strategy was to have the developer https://gist.github.com/cjsauer/9ab075ca995d7ee855040271c766db27#file-authorization-clj-L14 when creating the pathom plugin. In reality tho this is just a convenience. As for 2, here’s my thinking on the interface being (fn [env entity-ident user-ident]) hung on defattr. I want an interface that lets me surgically select an edge from the graph and answer the question “can this specific user perform c|r|u|d on this exact edge leading from this exact entity?“. The “this exact entity” part is what is difficult (for me at least) to generalize. With reads, it’s easy to just follow pathom’s parse, because it keeps track of the current entity for you. For form saves, it’s also easy, because the diff is in the perfect shape to make this trivial (https://gist.github.com/cjsauer/9ab075ca995d7ee855040271c766db27#file-authorization-clj-L60 over the [k v] tuples of that delta, calling the auth function on every key that is attempting to be modified. But for arbitrary mutations, just being handed an input alone is a bit tough like you said…I can’t quite see how I’d bend that to obtain entity-ident for every attribute in that input. === Here’s a thought that might help us ground this discussion: do you think that the ideal authorization interface would be (fn [env user e a v]) -> #{:c :r :u :d}? In other words, the most general access control would check every single datom that is attempting to be read, or that would result from a successful mutation. This is what’s been guiding my experiments. Can I reason about access at the fact level?

As a complex example, you could imagine an access control scheme that depends on all three e a v. Imagine a system where admins can schedule patients at any time of day, but “schedulers” are only allowed to schedule appointments between the hours of A and B. This would be access control that involves • e (which schedule we’re affecting) • a (the :appointment/time) • v (must be between hours A and B)

Remember that saves happen thorugh form diffs, which are normalized. There’s an ident, and then there are before/after values. Often for permissions you need all of the input/params to make your decision. I would not go for an EAV concept at all. The UI layer might just need a different option key, because those decisions are likely to be UI-centric, and less narrowly focused on data security. The server layer is what I’m speaking about, and at that layer you want the general env (which needs to be customizable) and then you always need every bit of context that is needed for the resolution of the request: The input (for resolver) or params (for mutation).

IMO, that is the most general way to go about it for the I/O layer at least…but the UI layer may in fact need a different mechanism.

for you example, imagine that the security of your scheduling system also depends on which doctor you’re seeing, and which insurance you have.

EAV is simply insufficient

> Often for permissions you need all of the input/params to make your decision. I would not go for an EAV concept at all. Hm yea, that’s a good point. EAV is too local, and not able to interact with other tuples. Very good point.

Back pedaling a bit, have you attempted to use your custom defresolver/mutation macros with RAD at all? How would they interact with the auto-resolvers for example?

Thinking more, EAV seems general enough to cover access control of reads, as I can’t think of interdependencies between the viewing of facts. Things like “you can only read X if you also read Y” just don’t really happen. However they fail when it comes to writes, which often have invariants that need to be upheld. Ignoring my flawed save/delete middleware, the wrap-read pathom plug-in solution I shared might still be viable.

Batching N+1 queries. Reads need a generalize input that is probably always a sequence so that you can resolve N things. Pathom started out with that morphing, but always making it a sequence turns out to be the right thing.

but there can be more than one fact required per input. A natural key, for example, might be two incoming facts to resolve one

this is why pathom inputs are sets

So, back to the drawing board. I oversimplified things chasing a fact based model. Thanks for your feedback @U0CKQ19AQ I think I’ll switch gears to something closer to your resolver/mutation level solution. I’m thinking I could use pathom :transform function to sprinkle in auth checks, and that those could potentially integrate with RAD’s generated resolvers quite easily.