Clojurians Log v2

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

(def webhook-handler
  (yada/handler
   (yada/resource
    {:methods
     {:post
      {:consumes #{"application/json"}
       :produces "text/plain"
       :response (fn [ctx] "worked")}}})))

curl -X POST -d '{"some":"thing"}' -H "Content-Type: application/json" localhost:3000/webhook

[deleted]

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})))

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

https://juxt.pro/blog/posts/yada-authentication.html

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

specifically this bit: https://cljdoc.martinklepsch.org/yada/yada/1.2.10/doc/basics/security/#basic-authentication

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:

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

this? https://github.com/juxt/yada/blob/master/src/yada/interceptors.clj#L418

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

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 🙂

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