funcool / buddy Goto Github PK

http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-21

In the provided session example, why the identity is located at [:session :identity] but the authenticated? fn only check if (:identity request) is true?

I'm using the Buddy wrap-access-rules. Currently I have a seq of rules of:

[{:uris ["/projects/:project-id" "/projects/:project-id/*"] :handler owns-project?}]

but when inspecting the request map in owns-project? the project-id is not in the there (the map is empty, in fact).

So the owns-project? function fails. What would be the best way of handling this? I'm using buddy-auth in my middleware like:

(def auth-backend
  (session-backend
   {:unauthorized-handler security/unauthorized-handler}))

(defn production-middleware [handler]
  (-> handler
     (wrap-access-rules {:rules security/rules} :on-error security/unauthorized-handler)
     (wrap-authentication auth-backend)
     wrap-restful-format
     (wrap-idle-session-timeout
      {:timeout (* 60 30)
       :timeout-response (redirect "/")})
     (wrap-defaults
      (->
       site-defaults
       (assoc-in [:static :resources] "public")
       (assoc-in [:session :store] (memory-store session/mem))))
     (wrap-internal-error :log #(timbre/error %))))

Looks like the documentation at https://niwibe.github.io/buddy/latest/ is out of date with the latest in the repo. Specifically, the lines:

;; Use them like plain secret password with hmac algorithms for sign
(def signed-data (sign "mystring" ec-privkey {:alg :ec256}))

;; And unsign
(def unsigned-data (unsign signed-data ec-pubkey {:alg :ec256}))

Should have :es256 instead of :ec256

Hi there,

I'm trying to build an example auth system using Buddy's token-backend authentication middleware.

The documentation says I need to call a auth-fn function:
It parses a token and passes it to auth-fn for authentication.

However looking at the src, I don't see the auth-fn function actually being handled by TokenBackend: https://github.com/niwibe/buddy/blob/master/src/clojure/buddy/auth/backends/token.clj#L74

Is this particular backend still a WIP?

https://funcool.github.io/buddy/latest/

java -version
java version "1.7.0_72"
Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)

With 0.2.0 I get:

CompilerException java.lang.UnsupportedClassVersionError: buddy/impl/BCrypt : Unsupported major.minor version 52.0, compiling:(buddy/hashers/bcrypt.clj:1:1)

That's not the case of 0.1.1. Is that a bug or 0.2.0 must be used with java 1.8 ?

Thanks for the work you have put on this library.

Geraldo

Keccak/sha3 digest and hasher

niwibe,

I have changed from 0.1.1 to 0.2.3 and also based my code on session-example, so I have an unauthorized-handler that redirects.

So after this redirect with 0.1.1
{:status 302,
:headers
{"X-Content-Type-Options" "nosniff",
"X-Frame-Options" "SAMEORIGIN",
"X-XSS-Protection" "1; mode=block",
"Content-Type" "application/octet-stream",
"Set-Cookie"
("ring-session=aab203ea-ad3a-49a2-a231-e8270472973d;Path=/;HttpOnly"),
"Location" "http://localhost:3000/login?next=/"},
:body ""}

And after 0.2.3
{:status 401,
:headers
{"X-Content-Type-Options" "nosniff",
"X-Frame-Options" "SAMEORIGIN",
"X-XSS-Protection" "1; mode=block",
"Content-Type" "application/octet-stream"},
:body "Unauthorized"}

It looks like the redirect from unauthorized-handler are not honoured anymore.

I've tested here and it seems that session-example suffers from this issue too.

Regards and thank you very much for buddy !

Geraldo

When pulling 0.12.0 I get this error:

clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: No such var: codecs/bytes->safebase64, compiling:(buddy/sign/jws.clj:79:9)
             java.lang.RuntimeException: No such var: codecs/bytes->safebase64

When pulling 0.13 I get the following error as well (I do not get why 0.13.0 is in the README while it is still 0.12.0 in project.clj). So I assume this is a versioning error somewhere.

In clojure tradition, there's often a section titled Rationale explaining your motivation for creating something. In this case, as a potential user I wonder why you wrote this when Friend is the current de facto auth library. I also want to know what the benefits and drawbacks of Buddy are compared to Friend.

After digging around, I found some compelling reasons to use Buddy and it would help others in the future to list these upfront in the README.

hi,
I couldn't use beta4 from lein because apparently (https://clojars.org/buddy) it's not updated there.

I'm a clojure newbie and I don't know how to use the github version from my project. Are you planning to upload beta4? or directly go to 0.2?

I get the following error with 0.6.1 release of the library. I don't experience the same issue with the previous version 0.6.0.

Caused by: java.io.FileNotFoundException: Could not locate cats/monad/exception__init.class or cats/monad/exception.clj on classpath:
at clojure.lang.RT.load(RT.java:443)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5066.invoke(core.clj:5641)
at clojure.core$load.doInvoke(core.clj:5640)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5446)
at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
at clojure.core$load_lib.doInvoke(core.clj:5485)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:626)
at clojure.core$load_libs.doInvoke(core.clj:5524)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:626)
at clojure.core$require.doInvoke(core.clj:5607)
at clojure.lang.RestFn.invoke(RestFn.java:805)
at buddy.sign.jws$eval20192$loading__4958__auto____20193.invoke(jws.clj:20)
at buddy.sign.jws$eval20192.invoke(jws.clj:20)
at clojure.lang.Compiler.eval(Compiler.java:6703)
at clojure.lang.Compiler.eval(Compiler.java:6692)
at clojure.lang.Compiler.load(Compiler.java:7130)
... 98 more
Subprocess failed

When I use jws backend and send request without Authentication header, the request goes through. I am not sure if it should be like this, because if I require the token to be there, it should fail.

I have a bad feeling I am missing something and that it's working as inteded and it is me who misconfigured something, but in that case I found no evidence of how to make that fail when header is missing.

I was wondering if you're happy with just BouncyCastle (which I totally understand), or if additions like libsodium (through kalium) are welcome.

I'm building something that needs strong symmetric crypto and strong (& fast) key derivation. Conveniently I only need 512 bits of keying material, so I repurposed BLAKE2b. 256 of those bits need to go into an authenticated encryption scheme, so I picked nacl/libsodium's secretbox.

My main reason for wanting secretbox is auditability: if an auditor sees that I'm using secretbox, they don't have to worry about checking if I got authenticated encryption right :-) However, since right now I'm just building a prototype, I can simply compose ChaCha20 + Poly1305-AES, which both seem supported :-)

Would you be interested in bindings to kalium/libsodium as well? (Please don't interpret this as a demand; if you're happy with BouncyCastle, you have every reason to be :-))

When I run the following

lein ring uberjar java -cp target/fb-backend.jar clojure.main -m fb-backend.handler

I get this

Exception in thread "main" org.bouncycastle.openssl.PEMException: Unable to create OpenSSL PBDKF: PBKDF-OpenSSL SecretKeyFactory not available, compiling:(handler.clj:193:14)

Caused by: org.bouncycastle.openssl.PEMException: Unable to create OpenSSL PBDKF: PBKDF-OpenSSL SecretKeyFactory not available

This occurs on a line that uses:

(def privkey (keys/private-key "keys/privkey.pem" "XXXXXX"))

I would like to deploy a backend to heroku that uses buddy, and compojure-api, and I need to compile it down to an uberjar, or else heroku's lein takes too long grabbing libraries and booting up.

I found this "lead" but I'm not sure what to make of it:
https://clojurians-log.clojureverse.org/clojure/2016-04-27.html
https://github.com/middlesphere/jwt-auth-service/blob/210e797802b4bf53bfd03aa639ede54a73154f4d/src/jwt_auth_service/core.clj

Thoughts?

I tried to implement token based auth in my application but the token-backend does not work for some reason.

I set up backend and handlers according to docs:

(defn authenticate
  [req auth-data]
  "test")

(def auth-backend
  (token-backend {:authfn authenticate
                  :unauthorized-handler unauthorized-handler}))

And my request handler looks like:

(def api
  (->
    (handler/api api-routes)
    (wrap-authentication auth/auth-backend)
    (wrap-authorization auth/auth-backend)
    (wrap-session)
    (wrap-restful-response)))

The method authfn gets never called and I can't authenticate user in any way using buddy. Is this backend broken?

Is a port to ClojureScript planned? I'm interested in verifying JWT's in the browser.

I didn't even notice the submodules were in separate repos.