This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (7)
- # bangalore-clj (11)
- # boot (70)
- # cider (11)
- # cljsjs (3)
- # cljsrn (17)
- # clojure (88)
- # clojure-brasil (8)
- # clojure-dev (17)
- # clojure-greece (1)
- # clojure-italy (6)
- # clojure-poland (8)
- # clojure-russia (2)
- # clojure-spec (44)
- # clojure-uk (32)
- # clojurescript (176)
- # cloverage (2)
- # component (5)
- # cursive (3)
- # datomic (23)
- # defnpodcast (6)
- # dirac (15)
- # emacs (6)
- # garden (19)
- # hoplon (126)
- # leiningen (1)
- # off-topic (3)
- # om (66)
- # onyx (56)
- # re-frame (8)
- # reagent (7)
- # ring-swagger (43)
- # specter (18)
- # untangled (110)
- # vim (3)
- # yada (39)
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
and each their own set of allowed fields in the body and a different authorization method
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
no, sorry @kardan -it is still a TODO here; https://github.com/juxt/yada/blob/master/src/yada/oauth.clj
@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.
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
ok, and none of the built-in interceptors rely on
(-> ctx :parameters :header) to calculate e.g. representation?
technically headers can play a role in content negotiation, but I haven't thought hard about that yet
While browsing though http://juxt.pro/yada site I’m seeing some other errors. Should I report them/fix them somewhere?
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.