Clojurians Log v2

will be available for both, not public yet

but just for the fun, I did some changes, for the curious ones, this is what its looking now:

Hello 🎃 I did a small prototype of a possible connector between #re-frame and #pathom I would like some feedback of any kind There is 3 main points: - A reg-fx that simply call the parser. it receive a eql query and return's a result - A tree->db function, that ✨ smartly ✨ merge the db with the result, using the query and it's metadata to do the normalization stuff - A db->tree function, that given a query, it denormalize the DB The data fetched will be normalized as you describe in the query. The final DB can be like a #fulcro db, where you want, or a regular "deep tree db" if you prefer. You will not need to create tons of reg-sub or reg-event, but you can create or migrate slowly as you need. https://github.com/souenzzo/souenzzo.github.io/blob/master/eql-refdb/dev/sample/app.cljs

I need to restrict queries based on the current user, so I want to write a plugin that is able to provide a map about the current user to the queries using the ring session data. I don't want to trust anything the client sends about who the current user is other than trusting the session token. Is a plugin the right approach? Are there any examples out there on how to do this? Thanks

To add, we're using Fulcro so http://book.fulcrologic.com/#_example_securing_a_normal_remote is an option. However, I'm still unsure how to pass additional data that isn't part of the client query to Pathom

There is some topics here https://github.com/souenzzo/eql-style-guide/issues/4 Any standard/final solution AFIK

we’ve had to do something similar. We convert the token into a user id in the middleware and jam the user id into the env when the parser executes. datomic is our primary backend datastore, and we have some rules that limit the results based on the user. For mutations we just check the perms with a wrapper around the ‘real’ function. I messed around with a plugin approach but it was hard to make it work ‘generically’

> and jam the user id into the env This is the part I haven't figured out yet. Is there an example you could share?

sure one sec

Ah ok. I did not think to look at eql-style-guide. Thanks

I’ve pasted in some bits from one of my projects ( this assumes the typical project layout)

; in x.x.server-components.middleware.clj
(defn wrap-api [handler uri]
  (fn [request]
    (if (= uri (:uri request))
      (handle-api-request
        (:transit-params request)
        ; we do the whole request, but you could say just pull the auth header here 
        (fn [tx] (parser {:ring/request request} tx)))
      (handler request))))
; in .x.x.server-components.pathom
;; we wrap this func with core.memoize
(defn userinfo
  "get the userinfo from auth0"
  [env]
  (let [req (:ring/request env)]
    (log/debug :req req)
    (when-let [token (get-in req [:headers "auth-token"])]
      (log/debug "got token" token)
      (log/spy :debug (get-userinfo token)))))
;; in your parser setup
...
::p/plugins [(p/env-wrap-plugin (fn [env]
                (assoc env :userinfo (userinfo env)) 

                       ]
...

I pulled out superfluous stuff that we use. but basically use p/wrap-env-plugin to jack what you’d like into the env

Nice! Thanks a lot @eoliphant! 🔥

np 🙂

it’s nice bc our specifics (e.g. Auth0) don’t leak any further, and our users have ‘our’ internal UUID and an external-id attribute that we map to what we get back from auth0 (e.g. auth0|xxxxxx), such that we can have multiple providers or switch from one to another

Cool cool cool. We've taken a similar approach with ids. I'm curious, why did you choose Auth0? I assume your app doesn't have any concept of groups of users or sharing between users, right?

we’d already used it for some other stuff. and we really only use it for identity. Authorization, ‘relationships’, etc are managed in the app