Fork me on GitHub

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?


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."


@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


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


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


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


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


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


@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.


Would that point to use interceptors?


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!


@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.


@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.


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


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


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


no, not currently


if the tests pass, it's good


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


yada manual runs on yada I see 😬


I need to take that old site down


But yes, most of our sites run on yada


ah ok found it through google i guess


I imagine subdomain beats path in seo


While browsing though site I’m seeing some other errors. Should I report them/fix them somewhere?


Yada github is probably the best one for that.


I think they're generated from the asciidoc files there


Yada works really nice so far 🙂


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


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


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.


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.