Fork me on GitHub

Hey there. I’m using yada/lean with a handler like this:

(def webhook-handler
      {:consumes #{"application/json"}
       :produces "text/plain"
       :response (fn [ctx] "worked")}}})))
Now when I make a request using curl:
curl -X POST -d '{"some":"thing"}' -H "Content-Type: application/json" localhost:3000/webhook
I get 415 Unsupported Media Type@dominicm mentioned this may be because yada/lean doesn’t have yada/json but since I’m specifying that I’m able to handle json in the :consumes key I feel like that handler should accept json?


I’m having some trouble getting :access-control to do what I want. I use the following function as :verify

(defn auth [[user password]]
  (let [m {"cljdoc" "cljdoc"}]
    (when (get m user)
      {:user user})))
Now when I send a request with -u cljdoc:cljdoc there is no WWW-Authenticate header returned. In contrast when I send a request with -u foo:bar there is a WWW-Authenticate header returned. In both cases the handler runs as if authentication returned a value which, i.e. the handler is run. This is confusing with regards to this quote from the yada docs: > However, if you return nil, this will be treated as no credentials being sent and a 401 Unauthorized response will be returned.


I get it to work if I set :authorization for the given method but I’m not sure if using these two in combination is required? The docs seem to treat them as separate concerns?


:authorization is about a minimum set of requirements for who is/isn't authenticated. You could say that unauthenticated users are :user, normal users have :user, and admins have :admin.


Hi @martinklepsch sorry this is late. I'm a bit confused - your auth function is returning non-nil with cljdoc:cljdoc, so that means it's passing the authentication check. That means there won't be a 401, so no WWW-Authenticate header


there is a built-in "Basic" defmethod, where "Basic" will be sent back in the WWW-Authenticate header. If your defmethod uses a string rather than a keyword then the behaviour is slight different


So in summary I'm a little confused -could you expand on what you're seeing?


@malcolmsparks I was expecting that I could restrict access to a resource using just the :verify/ Authentication functionality. It seems that this kind of thing requires the user of :authorization though.


basically there does not seem to be a way to return 403 just by returning some value from :verify


Ah. I understand now. You cannot restrict a resource with authentication only. Its only a step of establishing credentials. Think of this as a passport. If you want to restrict access you need an authorisation step. Think of this as a border guard who checks the passport and visa and possibly other credentials and documents


This is not how other Web frameworks interpret http


Got it, I kind of figured that this may be the thinking here but I found the docs a bit confusing then


The blog article is better than the docs right now. But we're going to improve the docs soon especially with cljdoc right.?


> If you return an empty map (a truthy value) and the resource requires credentials that aren’t in the map, a 403 Forbidden response will be returned. However, if you return nil, this will be treated as no credentials being sent and a 401 Unauthorized response will be returned.


Didn’t even look for a blog post 😛


Ah that's wrong. I need to rewrite that section


unrelated other newb question: how to return empty body with 200 OK?


Dominic mentioned just (assoc-in ctx [:response :status] 200) but with text/plain that will print the entire context 🐵


@martinklepsch you want more like (assoc (:response ctx) :status 200). :response is a record in Yada, so it can be distinguished from other maplike objects


if you want to be http compliant, you should probably return 204, so that it's clear that client shouldn't expect any other data from the server


@danielcompton that does the trick! @wdullaer thanks good point 🙂


I wonder if yada handles "" as 204 :thinking_face:


if you assoc it, it'll set it. I seem to remember that if you send an empty reply it does just set 204 as the status, but it's been a while. seems easy enough to test 🙂


Is there a go-to way to print exceptions somewhere?


Do I need to write an interceptor or is there something basic built-in?


There's a logging chain, which might be useful


@dominicm can you think of any example code that I may be able to steal from? 😛


We use it internally, I don't know of anything public. Unless someone added tests for the feature.


Something seems to be really broken in my project in that I can’t log anything even just using plain log/info at the repl 🙈


Hmm. That could be the async nature of manifold, and binding conveyance.


Can you log to a file or via logback?


@martinklepsch yes. That logging interceptor was added for a juxt client. You can use it.


From the code you add :logger of course


It is a problem that yada only really shines for the devs who get it and have figured out how it hangs together. Often you need some familiarity with the source.


Docs will help


(I am resolved to redouble my efforts to provide better docs)


You say this and yada already has some of the nicest docs on the block 😛


Too kind. The docs are rather incomplete