Fork me on GitHub
#yada
<
2017-02-09
>
malcolmsparks08:02:38

@stijn json rendered errors were temporarily removed for 1.2.x because of rendering issues when errors contained types not possible for cheshire to render. I will look at fixing this.

stijn08:02:57

is there a way to override that behaviour?

malcolmsparks08:02:36

Are you prepared to fork temporarily?

stijn08:02:13

possibly, but that's always a hassle with git submodules and lein checkouts 🙂

stijn08:02:20

through :responses maybe?

malcolmsparks08:02:21

The issue is that only text/plain is declared so conneg chooses it

stijn08:02:44

but text/html and application/edn seem to work?

malcolmsparks08:02:47

Custom responses should be fine

malcolmsparks08:02:09

I need to refresh my memory by looking at code.

stijn08:02:22

I'll go with :responses for now

malcolmsparks08:02:26

I will my this my next yada task because it's currently a breakage with 1.1.

malcolmsparks08:02:28

I was under a bit of self-induced pressure to release and error handling was sacrificed on the altar of speed. Poor choice in retrospect.

stijn10:02:18

question about authorization on datomic with yada:

stijn10:02:38

I would think it's best practice to do the authorization inside a database function

stijn10:02:21

as e.g. a user might have been blocked, or roles might have been retracted between the incoming call and the actual point of executing the transaction

malcolmsparks10:02:14

I deref the connection to get a db value in an interceptor

stijn10:02:37

that would mean I have to (at least for put/post) handle the authorization in the :response instead of using the security interceptors of yada

malcolmsparks10:02:43

I think consistency is more useful

stijn10:02:58

@malcolmsparks yes for reads that's ok, but writes

malcolmsparks10:02:07

I feel http requests should have ACID properties

malcolmsparks10:02:34

Are you doing long async gaps in your requests?

stijn10:02:02

no, but you don't know how fast or slow the transactor is

stijn10:02:32

and you can only guarantee ACID if you let the transactor do the validation

malcolmsparks10:02:57

What does Datomic's sync call do. Might be relevant

stijn10:02:29

yes that's a good point. I was just going to write: 'my peer might have a very old db value'

malcolmsparks10:02:41

If you're worried about transactor queues, i'd steer clear of tx fns

stijn10:02:52

but still, between sync and transact, something might have changed

stijn10:02:38

there's 2 things that we would like to do inside the transaction: semantic validation of the incoming request and authorization whether the user can update that specific entity

stijn10:02:38

depending on the exception thrown by the transaction, we would generate a 422 (i guess) or a 403.

stijn10:02:16

it's not that bad really, we just wrap every call to d/transact with error handling that will generate the appropriate error codes

stijn10:02:24

but it got me thinking about the split between the authorize and invoke-method interceptors

stijn10:02:52

I guess there will never be a one-size-fits-all HTTP best practice 🙂