Fork me on GitHub
#yada
<
2016-10-11
>
stijn08:10:48

http question: for a user resource with PUT method that updates the user details, there is supposed to be different behaviour based on the role of the user. i.e. a normal user can only update certain fields of his own user resource, but an admin can update additional fields 'roles' and 'blocked?'. What would be a good response for a normal user that includes updates to these fields in the body: 400 bad request or 403 forbidden?

malcolmsparks08:10:24

My vote would be 403, on balance. A 400 indicates a 'bad' request, which implies to me that there's something malformed: "The request could not be understood by the server due to malformed syntax."

malcolmsparks08:10:10

@stijn so it feels to me that a 400 isn't the right response here, but it's really about what you think would best indicate the best course of action to the client

stijn08:10:21

yes, it's a bit weird, maybe I'm going to split it into 2 different resources

stijn08:10:57

and each their own set of allowed fields in the body and a different authorization method

malcolmsparks08:10:51

yes, that makes sense - a separate resource for those additional fields

kardan09:10:04

Is there any examples of how to do something like refreshing tokens when using openid-connect?

kardan09:10:32

I’m not sure if I should start looking at interceptors or if there is some other path to go

kardan09:10:38

@malcolmsparks yes been looking at that namespace. I do want something for all or most resources, that happens before the (verify ) auth fn is getting called.

kardan09:10:49

Would that point to use interceptors?

kardan09:10:04

I’m not stating good questions, doing some learning when I have time. Should go back and fiddle to get a better understanding of Yada. & thanks for all the work!

malcolmsparks10:10:01

@kardan Yes, you can break yada apart and rebuild it by putting the interceptors back in a different order. That is an intentional part of the design.

stijn11:10:36

@malcolmsparks question on the header coercion: I was looking to make a pull request, but was wondering what is the impact on other functionality in yada like content negotiation, cache/etag headers, ... if we start to allow coercion of headers.

malcolmsparks13:10:01

if it's not declared as a header parameter (and thereby requiring coercion), I assume we should leave all other headers as they are, so we only coerce header values, and perhaps require that certain headers are required/optional, but all others are implicitly allowed

malcolmsparks13:10:21

i.e. we never send a 400 because of a request header that we don't know about

stijn13:10:31

ok, and none of the built-in interceptors rely on (-> ctx :parameters :header) to calculate e.g. representation?

malcolmsparks13:10:20

no, not currently

malcolmsparks13:10:28

if the tests pass, it's good

malcolmsparks13:10:14

technically headers can play a role in content negotiation, but I haven't thought hard about that yet

jeroenvandijk16:10:03

yada manual runs on yada I see https://yada.juxt.pro/manual 😬

malcolmsparks17:10:34

I need to take that old site down

malcolmsparks17:10:55

But yes, most of our sites run on yada

jeroenvandijk17:10:03

ah ok found it through google i guess

dominicm17:10:01

I imagine subdomain beats path in seo

jeroenvandijk17:10:59

While browsing though http://juxt.pro/yada site I’m seeing some other errors. Should I report them/fix them somewhere?

dominicm17:10:58

Yada github is probably the best one for that.

dominicm17:10:15

I think they're generated from the asciidoc files there

jeroenvandijk17:10:36

Yada works really nice so far 🙂

jeroenvandijk17:10:43

One difficulty I’m having was/is the large number of dependencies. Is the idea to split up the project at some point?

dominicm18:10:15

I've not heard of any plans to do that. I'm pretty sure every dependency can be justified.

jeroenvandijk21:10:37

I’m sure all dependencies have a use, I don’t want to question that. For my use case though, the json feature and therefore the dependeny would not be necessary, but yada requires it, just like transit etc. All very useful for most applications, I can see that. I’m trying to integrate Yada with an application that already has many dependencies, so then this becomes a bit troublesome.

jeroenvandijk21:10:45

I don’t want to complain though. I can understand that it makes sense for the use case of the authors. I can manage by applying :exclusions in my project and picking the right namespaces.