Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2017-03-22

Channels

#yada
<
2017-03-22
>
snorremd08:03:55

Edit: Problem solved. I juse needed to provide an authorization scheme as well. 

{:scheme :deny-all
                       :authorization
                               {:methods
                                {:get :foo.bar.baz}}}
Hi. I'm struggling with access-control in yada. I've defined a verify method that should always deny access. As far as I can tell from the documentation, returning nil should make Yada return a 401 response. 
(defmethod verify :deny-all
  [ctx _]
  (clojure.tools.logging/info "DENY REQUEST, RETURN NIL!")
  nil)
I then set the resource's :access-control to use the :deny-all scheme: 
:access-control {:scheme :deny-all}
The server does log the "DENY REQUEST..." string, but goes on to handle the request with the :response handler. Am I missing something? I'm running Yada 1.2.

dominicm09:03:24

Very interesting discussion about a pitfall of using spec for forms yesterday. If you call s/keys on a map you got from a user (e.g. via a submitted form), it could contain a key of :some-library/slow-to-validate-spec. That opens you up to ddos attacks quite easily. A caution for anyone here already doing that is all.

dominicm09:03:55

Apparently you should validate input before passing it to s/keys. Feels a little "Yo dawg" to me.

malcolmsparks09:03:51

@snorremd I have a full article almost ready about auth

mpenet09:03:01

if you keywordize your json via (keyword nil k) it should be safe

malcolmsparks09:03:06

Happy to send you a link to the draft if it would help

snorremd14:03:11

Just a tiny reminder about that draft link. You can direct message it to me if you don't want to share it publicly.

snorremd09:03:22

@malcolmsparks I believe that would be very helpful indeed. I'm just about to start implementing JWT based authentication for my Yada-based API.

dominicm10:03:20

@snorremd jwt is already implemented

malcolmsparks10:03:39

Yes. But not well documented

dominicm10:03:27

Also missing a plain ol' jws implementation from the same library. I have one lying around I need to PR back.

snorremd10:03:15

@dominicm Yeah, I saw. Though as far as I could see it assumes the JWT is passed as a cookie value.

snorremd10:03:42

I would likely want to use a request header instead (the API is not browser-facing).

dominicm10:03:47

Would be good if it could take a function to look it up in the ctx 🙂

snorremd10:03:06

That would help. Perhaps also an optional map of buddy.jwt/unsign options. edit: As of now buddy.sign.jws/unsign defaults :alg to :hs256. I also believe it would be practical for testing purposes to be able to specify :now. This will allow you to pass a hard-coded JWT with an old exp value, and then make buddy travel back in time so it does not fail the old token.