Clojurians Log v2

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

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.

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

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

Thank you!

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

Yeah that’s great!

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

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

yes, to be able to mock request, record request

also for the nonce generation i want to do the same

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

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

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

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

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

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.

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

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

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

I think the hardest part is the response body? Maybe inspiration could be taken from https://github.com/ring-clojure/ring/blob/6a1c7a17f9d1979ac00e3cb689ba0c1f61fe716b/ring-core/src/ring/core/protocols.clj#L19

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

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)