Fork me on GitHub
#juxt
<
2020-04-16
>
jeroenvandijk09:04:04

@malcolmsparks A first question around the OpenId code: https://github.com/juxt/apex/issues/3 . So far it’s pretty solid! I think I have some suggestions for extracting it into a seperate library, but the core looks good.

malcolmsparks09:04:56

Hi @jeroenvandijk - thanks - actually it's intended to be in a separate lib/jar so it can be used independently, but the idea is that all these components work well together and support the OpenAPI standard. There are OpenID-Connect declarations in OpenAPI.

jeroenvandijk09:04:24

Yes that’s great and how I understood it. I’m using it now partially as a library. I only had to hack in oic.clj. In order to use my own http client and some other things

malcolmsparks09:04:32

(I've commented on your issue to keep the discussion there)

malcolmsparks09:04:29

Thanks for engaging with this - it's new code and hasn't had a lot of exposure yet - but I'm really trying hard to code against the standards and go the extra mile to implement the security stuff

jeroenvandijk09:04:45

Yeah that’s great!

jeroenvandijk09:04:51

I’ve dealt with openid in a different way, so it’s not all new, but you did a great job in actually checking the specs 🙂 I’m looking forward to use it and contribute back. Hope I can help you make it into a standard clojure library that is well tested and secure

dominicm10:04:39

@jeroenvandijk any reason to change the http client other than personal preference?

jeroenvandijk10:04:57

yes, to be able to mock request, record request

jeroenvandijk10:04:07

also for the nonce generation i want to do the same

jeroenvandijk10:04:43

And another reason, the chosen http client doesn’t exist on java 8

jeroenvandijk10:04:58

So I my suggestion would be to choose a protocol that can be implemented

jeroenvandijk10:04:23

Hopefully we can choose/create a protocol that can be supported by the greater clojure community

jeroenvandijk10:04:54

That is also something that is missing. Too much code that cannot be reused because of this missing abstraction

jeroenvandijk10:04:27

I will do a proposal later of how I think this could be solved

malcolmsparks14:04:12

That's useful to know. I've been trying to reduce the number of dependencies necessary, hence the design decision to use internal JDK packages wherever possible, and http://java.net.http struck me as a very nice http client - sad that it isn't available in Java 8 though. My plan for Apex is rather long-term so I expect the adoption of JDK 11+ will increase.

malcolmsparks14:04:45

That said, there's no reason there can't be an option map with a callback function for nonce creation and http code exchange.

malcolmsparks14:04:18

And yes, for testing, that would make sense too. You don't want to have a auth server in your testing setup.

dominicm14:04:43

The hard part is defining that interface really. Eg aws api takes a particular map and returns a channel.

jeroenvandijk15:04:14

I don’t have an opinion on the jdk client. I can imagine it’s a very well tested client. In order to create testable distributed architectures I always try to abstract the http layer (up until the level of dns). This makes tests less fragile as you don’t have start (and stop) servers

jeroenvandijk15:04:03

Ideally, the whole Clojure community would do this and we could be able to mock all external requests (like how you can do this in Ruby with https://github.com/vcr/vcr)